Ninety-Two Percent Forever
Meridian Health's claims team runs Scrum with seven Developers on two-week Sprints. Its Definition of Done requires code review and a passing automated build, but says nothing about regression testing, accessibility checks or release notes. For three consecutive Sprints the Product Owner has reported to the steering committee that the billing module is '92% complete', and for three Sprints the remaining 8% has not moved. Each Sprint the team starts new Product Backlog items and hands finished code to a separate QA group that tests at the end of a release cycle. UAT last month found 41 defects, 12 of them in features the team had reported as done. The steering committee has now asked for a weekly percentage-complete report for every team. Two Developers say privately that they 'know it is not really done' but do not raise it, because the Product Owner is measured on the reported number. Release is planned in nine weeks.
1. Which Scrum pillar is failing here, and what specific evidence in the situation supports that diagnosis rather than a simple 'the team is slow' explanation?
Read the worked answer
Diagnosis: transparency, with the failure cascading into inspection and adaptation.
- The Definition of Done exists to give everyone a shared understanding of what 'done' means. This DoD stops at the build, so the team and the steering committee are looking at two different products. The team's internal sense of done and the organisation's sense of released are not the same thing.
- The 12 defects found in UAT inside features reported as done are the proof. This is not an estimate error; it is a false statement about the Increment. When transparency is false, inspection produces wrong conclusions and adaptation makes things worse - here, more new items started on top of undeclared incomplete work.
- '92% complete' is itself a symptom. A percentage of a module cannot be verified against a DoD, so it is unfalsifiable. It has not moved in three Sprints precisely because it is not measuring anything real.
- The Developers' silence points at the values layer: without openness and courage, the team cannot make the problem transparent even if the process allows it. The Product Owner's measurement creates a disincentive to tell the truth.
So the primary defect is not velocity. It is that the Increment is not transparent, and every downstream decision - release date, staffing, steering-committee expectations - is being made on an artefact that does not reflect reality.
2. What changes would you propose to the Definition of Done and to reporting, and in what order? Justify the sequence.
Read the worked answer
Sequence matters: make work visible before changing what you measure.
- Surface the gap. Have the team compare its DoD against the 41 UAT defects and the organisational quality expectations. The goal is for the team to conclude, without being told, that the current DoD allows undeclared incomplete work. A DoD imposed by the Scrum Master will be gamed; a DoD the Developers create will be defended.
- Strengthen the DoD, not the ceremony. Add what the evidence demands: regression tests for changed areas, accessibility checks, release notes. If the organisation has a minimum standard, that is a floor, not a ceiling. Expect the immediate consequence: reported throughput will drop and the nine-week release date will no longer look achievable. That is good news arriving late rather than bad news arriving at UAT.
- Then change the metric. Replace percentage-complete with something verifiable: number of backlog items meeting the DoD, defect escape trend, and a forecast range for the release based on the new DoD. The old numbers and the new numbers are not comparable - say so explicitly.
- Re-forecast openly. With a stronger DoD, historic velocity overstates capability. Produce a range for the release and present the assumptions. This is the Product Owner's conversation to lead; the Scrum Master's job is to make the empirical basis credible.
Doing step 3 before step 1 would simply produce a new number that is just as disconnected from the work.
3. The steering committee insists on a weekly percentage-complete report per team. How should the Scrum Master respond without becoming obstructive?
Read the worked answer
Treat the request as a legitimate need expressed as an unusable metric.
The committee is asking for predictability and early warning. Percentage complete cannot deliver either, because nobody can verify it. Refusing outright confirms the stereotype that Scrum Masters block governance. Accepting it confirms the stereotype that Scrum produces numbers nobody trusts.
A workable response:
- Explain the failure mode with the evidence already in hand: three Sprints of 92% and 12 defects in 'done' features. The metric is not conservative; it is misleading.
- Offer substitutes that answer the underlying question. Which backlog items meet the DoD this week; what is the release forecast range and what would change it; what is the defect-escape trend; what are the top three risks.
- Make the Sprint Review the transparency event. The committee should be seeing a working Increment and hearing the Product Owner discuss progress toward the Product Goal, not reading a weekly percentage.
- Be honest about the transition cost. The first honest report will look worse than the last dishonest one, and someone will be blamed. Name that risk to the Product Owner and the committee in advance.
- Do not unilaterally redesign corporate reporting. The Scrum Master coaches the Product Owner to lead this, and escalates it as an organisational impediment if the committee insists on an unverifiable number after a fair explanation.
The line to hold is that any reported figure must be traceable to something a stakeholder could inspect.