10.7 Managing a Stage Boundary and Its Agile Workshops
Key Takeaways
- Managing a stage boundary ensures the project board can decide on the next steps.
- Its activities are planning the next stage, updating the project plan, updating the business case, reporting stage end, and producing an exception plan when required.
- The stage boundary is where the business case is re-tested against what has actually been delivered rather than against a forecast.
- Release planning workshops set which features land in which release for the stage ahead.
- An exception plan is produced through this process when a tolerance is forecast to be breached, replacing the plan it supersedes.
10.7 Managing a Stage Boundary and Its Agile Workshops
Quick summary: SB exists to ensure that the project board can decide on the next steps. It runs at the end of every stage except the last, and also when an exception plan is required. Release planning for the stage ahead happens here.
Purpose
The purpose of managing a stage boundary is to enable the project board to decide on the next steps: to review the stage just completed, provide the information needed to authorize the next, and confirm that the project remains justified.
Ensuring the project board can decide on the next steps identifies SB. Contrast with CS, which is about keeping the current stage within its tolerances.
Activities
| Activity | What it produces |
|---|---|
| Plan the next stage | The next stage plan, including its releases and tolerances |
| Update the project plan | Revised project plan and release map, reflecting actual delivery |
| Update the business case | Revised business case and benefit forecast, based on evidence |
| Report stage end | The end stage report — what was delivered, lessons, and the recommendation |
| Produce an exception plan | Only when a tolerance has been forecast to be breached and the board has requested it |
Why the stage boundary is a governed agile project's strongest point
In a plan-driven project, a stage boundary decision is made largely on forecast: a percentage-complete figure, a schedule and a spend profile. The board is being asked to judge the future from an account of the past that it cannot independently verify.
On an agile project the boundary decision is made against product that exists:
- What was actually delivered — releases that work, that users have, and that can be inspected
- Measured benefit where releases have been in use — the benefit forecast can be corrected with data
- Demonstrated throughput — velocity across the stage gives an evidence-based forecast for the next
- Real quality position — defect rates and technical debt, not assurances
This makes the ensure continued business justification principle genuinely operational. The board can ask is this still worth doing? and answer it from evidence.
It also makes stopping easier and cheaper. If the evidence says the benefits are not appearing, the board can stop the project having banked the value of the releases already made — which is a very different proposition from abandoning a project that has produced nothing usable.
The stage/release/iteration relationship
Stage boundaries are set for management reasons: where the risk profile changes, where a large investment decision falls, where a major release lands, where the board needs a genuine option to stop.
Stages are not set to match iteration length. A stage typically contains one or more releases, each containing several iterations. Aligning a stage boundary with a release boundary is often sensible — the board gets to inspect a real release — but a stage is not obliged to contain exactly one release.
Release planning
Planning the next stage is where release planning does its work: deciding which features land in which release across the stage ahead. The release planning workshop brings together the project manager, chief product owner, product owners and team representatives to:
- Review the project backlog and its priority order
- Assign features to releases, respecting dependencies and team capacity
- Update the release map so the board can see what lands when
- Identify cross-team dependencies and agree how they will be managed
- Confirm the benefit each release is expected to start unlocking
The release map that comes out of this feeds directly into the board's authorization decision.
Exception plans
When a tolerance is forecast to be breached, the project manager raises an exception report. If the board decides the project should continue on a revised basis, it requests an exception plan, which is produced through this process.
An exception plan:
- Covers the period from the present to the end of the plan it replaces
- Explains the cause of the deviation and the options considered
- Is approved by the board at the level that owned the plan being replaced
- Replaces the plan it supersedes and becomes the new baseline
Note that an exception plan is produced through SB even though the stage has not ended — this is the second circumstance that triggers the process.
Agile tailoring of SB
- Review working product, not documents. The end stage report describes what was delivered, and the delivery itself can be demonstrated.
- Update the release map as a first-class output, since it is the artifact the board reads.
- Re-forecast benefits using measured data from releases already in use.
- Use velocity for the next stage's forecast rather than re-estimating from scratch.
- Right-size the end stage report. It summarises the delivered increments, tolerance consumption, benefit position, risks and lessons — drawn from dashboards rather than written afresh.
- Feed lessons forward. Retrospective themes from the stage inform how the next stage is set up.
Which activity is part of the 'managing a stage boundary' process?
What makes a stage boundary decision stronger on an agile project than on a plan-driven one?
Which statement about an exception plan is correct?