Stage Boundary When the Sprint Went Badly
On the Halcyon payroll migration project, the second management stage contains four two-week sprints. Sprint 3 failed its sprint goal: the team committed to 40 story points and delivered 18, because an upstream data-quality issue was worse than expected. The stage boundary is in one week. The project manager, Aisha, must decide whether to recommend that the stage be closed and the next stage started. The board's tolerance for stage slippage is two weeks. The end-of-stage report currently says 'on track'. The team lead argues that 'agile teams don't do stage boundaries-just keep sprinting'.
1. Should Aisha recommend closing the stage? Justify your answer using PRINCE2 Agile's approach to stage boundaries and health checks.
Read the worked answer
Yes-she should recommend closing the stage, but with an honest end-of-stage report, not the current 'on track' version. PRINCE2 Agile does not abolish stage boundaries; it aligns them to sprint/release boundaries so they are cheap to run and evidence-rich.
The evidence argues for closing:
- The stage has delivered less than planned (a known, quantified shortfall), and the cause (upstream data quality) is a stage-level risk that the next stage must be planned around.
- Closing the stage is the mechanism by which the board re-baselines the next stage's plan in light of that evidence. Continuing to sprint without a boundary would carry the shortfall forward invisibly.
- The two-week slippage tolerance is not yet breached, so this is a 'manage by exception' situation-report the forecast, let the board decide, don't pre-empt them.
The team lead's 'no stage boundaries' view misreads PRINCE2 Agile: boundaries are retained precisely so that governance and delivery stay connected. What is tailored is their weight-they should be short and use sprint artefacts as evidence.
2. How should the end-of-stage report be corrected, and what should it contain?
Read the worked answer
The 'on track' wording is a transparency failure and must be corrected before the board sees it. It should state:
- What was actually delivered against the stage plan-including the 18-of-40 sprint 3 outcome and its cause.
- Forecast for the remaining sprint(s) and the effect on stage end date, measured against the two-week tolerance.
- The upstream data-quality issue as a risk with an owner, likelihood, impact and proposed mitigation in the next stage plan.
- Lessons-e.g. estimation or discovery was insufficient; the next stage plan should include a spike or data-quality gate.
- A recommendation: close the stage, approve the revised next-stage plan, and note any tolerance position.
Aisha should also flag the health check implication-if the team reported 'on track' while a sprint was failing, the project's transparency and collaboration health are suspect and should be examined, not just the numbers.