Professional Scrum Master I (PSM I): The Percent-Complete Field

Primary casualty: Transparency - with Inspection and Adaptation failing as consequences.

Empiricism works as a chain: transparent artefacts → meaningful inspection → informed adaptation. Evidence in the scenario, in order of strength:

• The '% done' field measures across the Definition of Done boundary. Work that is coded but untested and undocumented is not Done. '80%' is an invented unit, not a description of the Increment.
• Downstream decisions rest on the distorted number. The Product Owner is forecasting to a steering committee from it, so the ordering and stakeholder expectations are being adapted to fiction.
• The staging failure contradicts the reported state. That is the empirical system rejecting the claim - the most concrete signal available.
• Silence at the Retrospective shows the inspection mechanism itself is compromised, not just the data. A team that cannot inspect its own process cannot adapt.

Note the precision required: transparency is a property of the artefacts and the Definition of Done, not a general comment on honesty. The team may be entirely well-intentioned and still be opaque.

Should do:

1. Make 'Done' explicit and binary. Facilitate the Developers in writing a Definition of Done the Increment can be checked against. Once it exists, the '% done' field has no honest value between 0 and 100 except Done/not Done.
2. Let the Developers tell the truth themselves. The Scrum Master does not report status on the team's behalf; they create the room for the Developers to state the real position to the Product Owner.
3. Coach the Product Owner on what the field actually measured and what a trustworthy forecast looks like (Done increments plus remaining backlog size, expressed as a range).
4. Escalate the organisational impediment - the programme office's demand - because the Scrum Master serves the organisation as well as the team.

Should not do: rewrite the steering committee deck, apply pressure to the two Developers who spoke up, add a testing gate as a 'compromise', or convert the Retrospective into a root-cause interrogation. None of these restore transparency; they relocate the problem.

The Scrum Master has no authority to overrule the Product Owner or management - influence, evidence and coaching are the levers.

Separate the genuine need from the format.

The need is forecast confidence. The format ('percent complete' inside the Definition of Done) is the part that corrupts the artefact. Options that satisfy both:

• Populate the field from the Definition of Done only - 0% or 100%, with the regulatory report aggregating Done items against the Product Goal. Nothing in Scrum forbids external reporting; it forbids reporting that misrepresents the Increment.
• Report a burn-up of Done work plus a range forecast for the remaining Product Backlog, with the uncertainty stated explicitly. Regulators generally prefer a range with assumptions over a false point estimate.
• Show the age of unmerged or untested work - the three-Sprint divergence becomes visible rather than smoothed away.

If the programme office insists on a non-binary measure, the Scrum Master documents it as an organisational impediment and continues to coach. The team's obligation is that their artefacts are transparent; the organisation's obligation is not to demand a number the artefacts cannot honestly supply. Do not resolve the tension by having Developers guess a percentage.