Three Hundred and Forty Items, No Goal
A team's Definition of Done has seven checks: code written, peer reviewed, merged to main, unit tests pass, no Severity-1 defects, release notes drafted, Product Owner demo done. Missing: deployed to a staging environment, integration tests, security review - the last is performed by a separate team during the release Sprint. The Product Backlog holds 340 items with no Product Goal; the top 40 are ordered by 'who complained most recently'. The Sprint Backlog is a flat Jira list with no Sprint Goal. Two weeks ago a defect that integration tests would have caught reached production; the team now proposes a two-week 'bug Sprint'.
1. Identify which artifact commitments are missing or weak, and state what each omission costs.
Read the worked answer
Each Scrum artifact carries a commitment that makes it inspectable:
| Artifact | Commitment | Status here | Cost |
|---|---|---|---|
| Product Backlog | Product Goal | Absent | Without a target, ordering degrades to whoever is loudest. 340 unordered items is not a backlog, it is a wish list; nobody can say whether the product is getting closer to anything. |
| Sprint Backlog | Sprint Goal | Absent | The Sprint cannot be inspected for progress toward an objective, only for ticket closure. This is also why the Daily Scrum has nothing to adapt. |
| Increment | Definition of Done | Present but weak | 'Merged to main' is not releasable. Each Sprint ends with an Increment that cannot be shipped, so the Sprint Review inspects a fiction. |
The linkage matters more than the three separate findings. Weak DoD produces escaped defects; escaped defects create pressure for a bug Sprint; bug Sprints consume the capacity that a Product Goal would have directed. The absent Product Goal is not a separate housekeeping issue - it is why the team has no basis for refusing work that does not serve a purpose.
2. Evaluate the 'bug Sprint' proposal using the Definition of Done, and propose an alternative the team can sustain.
Read the worked answer
The bug Sprint is a symptom treatment. It absorbs the consequence of a Definition of Done that stops at 'merged to main'. Two weeks of defect fixing changes nothing about the process that produced the defects, so the next bug Sprint arrives on schedule. It also stops the team producing new value for two weeks, which the Product Owner will feel and eventually overrule.
The real question is why integration tests are outside the DoD. If the answer is 'that environment is run by another team', the DoD is describing an organisational boundary, not quality. If it is 'integration tests are slow', the DoD is describing a capacity problem. Neither is a reason to declare merged code Done.
An alternative that holds:
- Strengthen the DoD now to include what would have caught this defect (integration tests passing, deployed to staging). If the organisation has a minimum standard, the team's DoD must at least meet it.
- Ring-fence the enabling work. Get the Product Owner to order automation and environment work at the top of the Product Backlog with a visible amount each Sprint - 20% is a common starting point, chosen with the PO, not by the SM.
- Expect a dip and pre-announce it. Points per Sprint will fall while the new DoD bites and existing unfinished work is caught. Warn stakeholders before the chart moves.
- If a dedicated defect window is genuinely needed, cap it. One Sprint with a specific, measurable exit condition ('integration suite green on all supported browsers') is defensible engineering. An open-ended bug Sprint repeated quarterly is a hardening Sprint under another name.
3. The Product Owner says a Product Goal is impossible with 340 competing items. How do you help, and what distinguishes a Product Goal from a release plan or a roadmap date?
Read the worked answer
Start by reframing the obstacle. The Product Owner is describing the backlog as an input - 340 demands to be serviced. A Product Goal is an output statement: the future state of the product the team is trying to reach. You cannot order 340 items without it, because there is no criterion for ordering. The absence of a goal is the reason the list looks impossible.
Practical help, not a lecture:
- Ask one question: 'If we shipped everything in the top 40, what would the product do that it cannot do today?' If the PO cannot answer, that is the goal - the absence of an answer, not a lack of time.
- Then ask which of the 340 items would not move the product toward that state. Those items do not get deleted; they lose their claim on near-term capacity. The list usually halves.
- Make it a draft and revise it. A Product Goal is a commitment, but it is replaced when the team learns something; it is not carved in stone.
What it is not:
- Not a release plan - a release plan sequences deliverables with dates; the Product Goal describes a state the product reaches.
- Not a roadmap date - 'Q3' is a time constraint; the Product Goal is a target the team steers by, and it can be reached early or late.
The test: a good Product Goal is a sentence a Developer can use to reject a request mid-Sprint without escalating. If it cannot do that, it is decoration.