The 92% Complete Sprint Review
Northwind Freight's Scrum Team has run two-week Sprints for eight months. At each Sprint Review the Product Owner presents a burn-down chart and states the team is '92% complete' against a fixed 18-month roadmap; the CEO has begun quoting these percentages to investors. The Developers have not integrated with the carrier API for four Sprints because 'the mock data is faster to demo'. Two weeks ago a pilot customer found that shipment labels printed with the wrong tariff - a defect the team knew about but did not surface because it did not fit the demo narrative. The Scrum Master has now been asked by the CEO for a 'confidence score' to add to the investor deck.
1. Identify the empiricism failures in this situation and explain which Scrum pillar each one undermines.
Read the worked answer
Transparency. '92% complete' is not a property of any real thing. Nothing in Scrum is percent complete; an Increment is either Done or it is not. Worse, the known tariff defect and the four-Sprint integration gap were deliberately left out of the picture, so the artifact inspected (mock data) was not the artifact being built.
Inspection. The Review inspected slides and mocks, not a usable Increment. Stakeholders therefore could not detect the gap, and a pilot customer did the inspecting instead - the most expensive possible moment to find out.
Adaptation. Evidence (a wrong-label defect, an unintegrated API) produced no change to the plan, because the plan is a fixed roadmap the team does not control.
The root cause is that the team is optimising for the appearance of progress against a fixed plan rather than for a transparent Increment and a Sprint Goal. The manufactured percentage is a symptom, not the disease - fixing the number without fixing the demo would change nothing.
2. The CEO asks for a confidence score. How should the Scrum Master respond, and what should replace the percentage?
Read the worked answer
Decline to invent it, and explain why in the language the CEO cares about: an unsupported number repeated to investors is a liability, not reassurance.
Offer instead what can actually be evidenced:
- How many Increments met the Definition of Done in the last six Sprints, and what 'Done' currently excludes (carrier integration).
- Sprint Goal outcomes - met, partially met, not met, with the reason. This is the most honest progress signal Scrum produces.
- Known defects and open risks, including the tariff labelling defect and the integration gap.
- A forecast with a range, derived from what the team has genuinely finished, with its assumptions stated.
Then reframe the request: 'You want to know whether we will hit the date. Here is what we know, what we do not, and what would have to change to improve the odds.' If investors need a number it should come from an evidenced forecast with named assumptions, never from a percentage of a plan nobody has re-examined in eight months.
3. What is the smallest change the team could make before the next Sprint Review to restore transparency?
Read the worked answer
Show the real thing. Concretely, and all achievable in one Sprint:
- Demo against the carrier sandbox rather than mock data, even if it is incomplete and visibly broken. A Review that exposes the integration gap is doing its job; one that hides it is not.
- Put the known defect list on the wall beside the Increment. Transparency is uncomfortable for one afternoon and cheap thereafter.
- Let the Developers present in their own words what is Done and what is not, instead of the Product Owner narrating a burn-down.
- Write a Sprint Goal for the next Sprint about a working end-to-end shipment label, moving integration from background annoyance to the thing being inspected.
The Review exists so the Product Backlog can be adapted based on what was learned. That cannot happen while the artifact on show is a slide deck, however polished.