Forecasting a Statutory Date with a Borrowed Specialist
A government digital service team has a statutory go-live date 14 weeks away and works in two-week sprints, leaving seven sprints including the current one. The remaining backlog is estimated at 240 story points; throughput for the last six sprints was 32, 41, 28, 37, 22 and 35 points. Two remaining items depend on a vendor API that is three weeks late, with no revised commitment. The only database migration specialist is allocated 50% to this team and 50% to supporting the legacy platform, and the accessibility tester required for the statutory assessment is shared across three programmes. Acceptance criteria on roughly a third of the remaining stories are still marked "TBC", and the two squads size inconsistently: one called a two-day task 8 points while the other called a five-day task 3. The steering committee has asked the delivery lead for "the delivery date and a Gantt chart showing confidence", and has already told finance the date will be met.
1. What can you say with confidence about the date? Show the calculation you would use and explain what you would present to the steering committee instead of a Gantt chart.
Read the worked answer
The honest answer is a range with probabilities, and the range straddles the deadline.
Arithmetic from the six sprints: throughput 32, 41, 28, 37, 22, 35. Mean = 195 ÷ 6 = 32.5 points per sprint; range 22–35.
- 240 ÷ 35 (best ever) ≈ 6.9 sprints - the only scenario that fits in seven.
- 240 ÷ 32.5 (mean) ≈ 7.4 sprints - misses.
- 240 ÷ 22 (worst) ≈ 10.9 sprints - misses by nearly four sprints.
So the deadline is achievable only if every remaining sprint matches the best sprint this team has ever had, and that is before the half-allocated specialist and the late vendor API are accounted for.
Three corrections to make before presenting:
- Stories with "TBC" acceptance criteria typically grow on elaboration; treat 240 as a floor, not a point estimate.
- Point sizing is inconsistent across squads, so cross-check throughput by story count and re-normalise sizing in the next refinement.
- Strip the 50% specialist allocation out as an explicit capacity assumption - if it stays at 50%, effective capacity drops and the range moves right.
Present: a burn-up against the required line, with a fan chart from a throughput-based Monte Carlo (or simply the three scenarios above) and a stated probability. Refuse the Gantt: a Gantt implies deterministic dependencies the team does not have and cannot show confidence. Also correct the finance assumption now - a forecast repeated becomes a commitment nobody agreed to.
2. Set out the adaptive planning actions you would take over the next three sprints, including how you handle the fixed date, the shared specialists and the late vendor API.
Read the worked answer
Treat the date as fixed, the scope as variable, and make the variability explicit and pre-agreed.
Sprint 1 (now):
- Convert "TBC" acceptance criteria into a refinement obligation - nothing enters a sprint without them. This is the largest hidden source of forecast error.
- Re-normalise sizing across the two squads using a shared reference set of three stories.
- Resolve the specialist allocation: negotiate 100% for six weeks with the legacy-platform owner, and record the trade-off they accept in writing. A 50% allocation on the critical path is a schedule risk disguised as a resourcing decision.
- Build the integration shell against stubs for the vendor API so the team's work is not blocked by the vendor, and escalate the vendor through the commercial owner with a dated request for a revised commitment.
Sprint 2:
- Deliver a thin end-to-end slice through the vendor integration to test the riskiest assumption early, not at the end.
- Sequence accessibility work in parallel rather than as a final gate; the statutory assessment is not a late-stage activity.
Sprint 3 - decision checkpoint:
- Pre-agree now, with the steering committee, a ranked list of what is dropped if throughput falls below 30 points per sprint at this checkpoint. De-scoping agreed in advance takes hours; de-scoping agreed in week 13 takes weeks and costs trust.
- Publish the burn-up at every checkpoint so the date conversation happens at week 6, not week 12.
Use a feature buffer sensibly: protect the fixed date by trimming scope at the edges, not by compressing testing.