Release health snapshot 02. Report Date: 17-08-2026
Priority changed.
The release system kept up.
iaci.tech can now publish reprioritised work outside the planned sprint sequence without rewriting the roadmap. [IW-302]
- Sequence preserved.
- Decision documented.
- History still true.
83SP
Delivered
Sprint 18 / IW-302 · 4-day window
23
Regression cases
Reusable Postman collection, UAT & PROD
16
Defects surfaced & resolved
14 of 16 caught before production
2
Publishing paths
Sequential + Prioritised, kept separate
Planned roadmap (sequential)
▲ Priority changed — S17 reprioritised and delivered early
Actual delivery
Active
Upcoming
Upcoming
✓ Prioritised · Completed
✓ Prioritised · Completed
★ THE VALUE
- Planned sequence is preserved.
- Prioritisation is visible.
- Decisions are documented.
- 2nd out-of-sequence release in program history — now a supported capability, not a repeated workaround.
Two truths. One reliable release history.
From workaround to capability
Capability added
| Before IW-302 | With IW-302 |
|---|---|
| Publishing assumed sequential delivery | Sequential and prioritised delivery supported |
| Reprioritisation existed only in Jira / backlog | Reprioritisation visible in product history |
| Out-of-sequence publishing required manual intervention | Dedicated ad-hoc publishing path |
| Changing delivery order risked confusing planned progression | Planned sequence preserved |
| API regression largely manual / feature-specific | Reusable Postman regression capability |
Two paths. One reliable release history.
Operating model
Sequential path
- Planned progression
- Advance lifecycle
- Maintain roadmap integrity
Prioritised path
- Priority changed
- Preserve sequence
- Record the decision
Architecture decision
Why not extend the existing API?
Considered: extend the sequential API
- Adds exceptional-case branching to a proven, production path
- Increases regression risk on working capability
- Blurs two different responsibilities into one workflow
Chosen: separate ad-hoc path
- Isolates reprioritisation from normal progression
- Preserves the sequential API's proven behaviour untouched
- Keeps each workflow's responsibility explicit
Testing that changed the outcome
Quality evidence
🛡
Severity spread (16 defects)
The decision is now part of the evidence
PM evidence
S14→S15→S16→S17→S18
Original roadmap
S17 reprioritised to deliver early
Why: product value and impact
S17 ▲ ✓ Prioritised · Completed
Visible in release history
Refined through testing: API Spec updated as defects surfaced; Test Strategy executed against it
Known limitations
- Prioritised sprints do not yet auto-transition status (Upcoming/Active → Completed) — status is currently set manually.
- Formal accessibility check for this report's own visuals — not yet executed.
Lessons learned
What's next — two lanes, one roadmap
Planned sequence: Sprint 14 — AI as a system, a tool, and a learning accelerator.
Prioritised pipeline: Product Management Dictionary, Product Management Framework.
Either lane can move when product value warrants it — without rewriting the roadmap to make history look linear.