412 Items and No Definition of Done
A product team's tool holds 412 backlog items, none ordered beyond the top 15, with no Product Goal recorded anywhere. Sprint Planning produces a list of 23 tickets, each assigned to one Developer before the Sprint begins. There is no written Definition of Done: 'done' means merged to a feature branch. Integration testing happens in a hardening Sprint every fourth Sprint. At the Sprint Review the Product Owner counts any ticket that has been coded as delivered. Three Sprints of work currently sit unmerged on branches. Last month's release shipped a defect the Developers had already found but not fixed, because 'it wasn't in the Sprint'.
1. Name the three artefacts and their commitments, then show for this team which commitment is missing or broken and what the consequence is.
Read the worked answer
| Artefact | Commitment | State here | Consequence |
|---|---|---|---|
| Product Backlog | Product Goal | Absent; 412 items with 15 ordered | No long-term objective, so ordering is arbitrary beyond the top of the list and every stakeholder request looks equally urgent |
| Sprint Backlog | Sprint Goal | Absent; 23 individually assigned tickets | No single objective for the Daily Scrum to inspect against; the plan cannot be adapted, only executed or abandoned |
| Increment | Definition of Done | Absent; 'merged to branch' is the de facto standard | The Increment is not a usable, releasable thing, so every other commitment floats |
The commitments are not paperwork - they are what makes the artefacts inspectable. Without a Definition of Done, the team cannot say what is complete; without a Sprint Goal, it cannot say whether the Sprint succeeded; without a Product Goal, the Product Owner cannot justify the order to anyone, including themselves.
The hardening Sprint is the symptom that ties them together: it exists because the team has no shared quality standard to reach each Sprint, only an occasional clean-up.
2. The Product Owner wants to present the three Sprints of unmerged branch work as 'about 70% delivered'. What happens to that work in Scrum terms, and what should the team say at the Review?
Read the worked answer
The rule: work that does not meet the Definition of Done is not part of the Increment. It returns to the Product Backlog for reordering. It is not partial delivery, it does not accrue credit, and the Sprint is not extended to finish it.
Applied here:
- The unmerged work is not an Increment. It cannot be inspected by stakeholders and cannot be released, so counting it as delivered is a transparency failure, not an optimism problem.
- 'About 70%' is the same fabricated unit as a percent-complete field: nothing in Scrum measures progress inside the Definition of Done.
- The defect found but not fixed because 'it wasn't in the Sprint' is the strongest illustration - the team had the information and no shared standard obliging them to act on it.
At the Review: show only what meets the Definition of Done. State plainly that three Sprints of work are unfinished and unevaluated, and put the Product Backlog decisions that follow on the table - reorder, re-scope, or drop. Stakeholders can handle bad news; they cannot handle discovering it later.
What must not happen: cancelling the Sprint to avoid the conversation. Only the Product Owner can cancel, and only when the Sprint Goal is obsolete - and there is no Sprint Goal here to become obsolete.
3. You can only fix things in sequence. What is the first move, and why not the more obvious ones?
Read the worked answer
First: establish a Definition of Done the Developers own.
Reasoning: every other repair depends on it.
- The Sprint Review cannot inspect an Increment that has no completion standard - you would be redesigning a demo of nothing.
- A Sprint Goal is only meaningful if achieving it produces something Done.
- The 412 items cannot be ordered sensibly while nobody knows what 'delivered' costs.
Why not the obvious moves first:
- Ordering the 412 items - the Product Owner will re-order against a fantasy of what things cost. Ordering on top of a broken quality standard produces a well-organised queue of unfinished work.
- Writing a Product Goal - valuable, but it will be a slogan until the team can deliver against it. Do it immediately afterwards, not first.
- Stopping the individual assignment in Planning - a real problem, but smaller. It is a self-management conversation the Retrospective can carry once the team has a shared standard to self-manage against.
- Killing the hardening Sprint - it will not survive a real Definition of Done anyway; abolishing it by decree just moves the testing debt earlier and invisible.
Practical detail: the Definition of Done is created by the Developers, not handed down. Where an organisational standard exists it is a minimum, not a substitute. With multiple teams on one product, they must define it mutually - which is exactly the failure mode in the next scenario.