The Definition of Done That Stops at Merged
Vantage Retail's Definition of Done states: code complete, unit tests pass, merged to the develop branch. In each of the last six sprints the team has carried an average of fourteen open defects into hardening, and releases happen every ten weeks after a three-week stabilization phase. The Product Backlog holds 620 items, most written as three-page specifications by a business analyst; ordering reflects the date each request arrived. There is no Product Goal. Two other teams work on the same product with their own backlogs and their own Definitions of Done. At the last Sprint Review, an executive asked whether the new checkout flow had increased conversion and nobody could answer.
1. Which artifacts and commitments are missing or weak, and what is the causal chain from those gaps to the ten-week release cycle?
Read the worked answer
Weak Definition of Done. Ending at merged means integration, end-to-end testing, and deployability sit outside the artifact. Work that is not in the definition of done is not visible as unfinished, so it accumulates silently. Each sprint adds unintegrated behaviour, and integration cost grows faster than the count of changes. The three-week stabilization phase is that cost arriving at once. The ten-week cycle is the consequence, not the policy.
No Product Goal. The Product Backlog is a 620-item arrival queue. Without a future state to serve, nothing can be deferred on principle, and ordering is a timestamp. The Sprint Goal, whatever it is, is whatever sits at the top.
Backlog items as specifications. Three-page specs fix the solution before any learning, so feedback arrives after build rather than before it.
One product, three backlogs, three definitions of done. There is no single Increment. Done means different things on adjacent teams, and integration debt is invisible on every board.
The chain: weak definition of done leads to non-integrated work, which requires a stabilization phase, which stretches the release interval, which slows feedback, which pushes more specification up front, which loads the queue. The executive's unanswered conversion question is the end of the same chain.
2. Draft the first three moves to strengthen the Definition of Done, and say what you would measure to show progress.
Read the worked answer
1. Make the gap transparent before changing anything. Have the Developers mark every open item against a proposed stronger definition, and publish the resulting gap. Do not grandfather silently. Measures: number of items not meeting full definition, and age of the oldest such item.
2. Strengthen the definition by one criterion at a time, owned by the Developers. Start with integrated with the other two teams and demonstrated end to end in a production-like environment. Add a criterion only when the team has met it consistently for two sprints; an aspirational definition that is routinely missed is worse than a modest one that always holds. Measures: percentage of items fully done at sprint end, starting from a baseline (expect around 40 percent) toward 90 percent plus, and escaped defect rate found after sprint end.
3. Instrument the path so the definition can actually be met. Automated regression on every merge, self-service deployment, and shared test environments across the three teams. Measures: time from merge to deployable, and length of the stabilization phase, which is the outcome the definition is meant to move.
Agree the product-level quality bar with the Product Owner, since some criteria cost value; the Developers own the definition, but the Product Owner must understand the trade.
3. How would you establish a Product Goal, and how does it differ in use from a Sprint Goal?
Read the worked answer
The difference is timescale and function. A Product Goal is a measurable description of a future state of the product that the Product Backlog exists to serve; it is a commitment on the Product Backlog. A Sprint Goal is one objective for one sprint that gives the team coherence; it is a commitment on the Sprint Backlog. The Product Goal filters the backlog. The Sprint Goal filters the sprint and allows scope to flex while the objective holds.
Establishing it. Work with the Product Owner, not for them. Start from the unanswered conversion question, because it is already the executive's language. Draft one outcome-based sentence with a direction and a rough horizon, for example that checkout abandonment falls materially within two quarters. Test it against the 620 items: anything that does not serve it is deferred or deleted, which is the point. Expect three or four drafts and a stakeholder conversation, and make the final version visible on the board.
Use it. In refinements, as the question that reorders. In Sprint Planning, as the parent of the Sprint Goal. In the Review, as the frame for the evidence: here is the movement toward the goal, here is what we now believe differently. A Product Goal nobody can fail is not a goal.