The Definition of Done That Isn't
A Scrum Team has a written Definition of Done: 'Code complete, unit tests pass, merged to main.' It has not changed in 14 months. The team's Increment is deployed to production roughly every six weeks, and each deployment requires a two-week manual regression cycle run by a separate QA group. In the last three months, 22 defects escaped to production; 9 were traced to integration gaps, 7 to missing non-functional checks (performance, accessibility), and 6 to environment differences between the team's test setup and production. The team's velocity looks healthy and stable. The Product Owner argues the DoD is 'fine' because the team meets it every Sprint. A new engineering manager wants to add 'deployed to production' to the DoD immediately, and the team says that is impossible because the regression cycle is owned by another group.
1. The Product Owner says the DoD is 'fine' because the team meets it. Explain why meeting the DoD is not evidence that the DoD is adequate, and connect the escaped defects to the DoD's content.
Read the worked answer
The Definition of Done is a commitment on the Increment - it defines what 'done' means so that the increment is transparently inspectable and potentially releasable. A DoD the team always meets tells you the team is consistent; it does not tell you the DoD is sufficient.
The test is whether the DoD produces an Increment that is genuinely usable and releasable. Here it doesn't:
- 'Merged to main' says nothing about integration - 9 escaped defects trace to integration gaps the DoD never checks.
- No non-functional criteria - 7 defects trace to performance/accessibility the DoD ignores.
- No environment parity - 6 defects trace to test/production differences the DoD doesn't address.
- The two-week manual regression owned by another group means 'done' is declared before the increment is actually validated for release. The team is meeting a DoD that stops short of releasable.
So the DoD is not 'fine'; it is a floor the team has mistaken for a ceiling. Stable velocity is consistent with this - the team is reliably completing work that is not reliably releasable. The escaped-defect pattern is the DoD's content, written in production.
2. The new manager wants to add 'deployed to production' to the DoD immediately. Evaluate this proposal. What does Scrum say about raising the DoD, and what are the risks of doing it abruptly?
Read the worked answer
The direction is right; the timing and ownership are wrong.
What Scrum says: the DoD should be raised over time as the team's capability grows, and it must be created and owned by the Scrum Team (with the organization supporting it). A manager imposing a DoD item unilaterally violates team ownership and usually produces either quiet non-compliance or a fake 'done.'
Risks of doing it immediately:
- The two-week manual regression is owned by an external QA group; the team cannot unilaterally make 'deployed to production' true. The DoD would be unmet every Sprint, destroying its credibility.
- Velocity would appear to collapse overnight, which invites the wrong conclusion (that the team slowed down) rather than the right one (that 'done' got more honest).
- The team would be blamed for a constraint it does not control.
Better path: treat 'deployed to production' as the target state and close the gap deliberately - negotiate the regression cycle with the QA group, add integration and non-functional checks, align environments - then adopt the DoD item when the team can actually meet it. The Scrum Master's job is to make the constraint visible to the manager and to remove it, not to let the team be measured against a DoD it cannot satisfy.
3. Propose a concrete plan to evolve the DoD over two quarters, including how the Scrum Master handles the external QA group and how the team communicates the likely velocity dip.
Read the worked answer
Quarter 1 - close the known gaps, keep the DoD honest
- Add to the DoD, with team agreement: integration tests pass in a production-like environment and agreed non-functional checks (performance threshold, accessibility criteria) pass. These are within the team's control and map directly to the 16 of 22 escaped defects they can fix.
- Work with the QA group to shift regression left: automate the highest-value regression cases and run them per-Sprint rather than in a two-week batch. Agree a joint target with the QA lead; the Scrum Master facilitates, the manager sponsors.
- Establish environment parity: align test and production configuration; make environment drift a tracked impediment.
Quarter 2 - make 'releasable' real
- Once regression is automated and environments align, add deployed to a production-like environment and validated - and, when the QA group's cycle is short enough, deployed to production.
- Re-baseline velocity after each DoD change and explain the dip in advance: 'Our number will drop because we are now counting more work as required. That is the number becoming more honest, not the team slowing down.'
Communicating the dip: tell the manager and PO before it happens, with the escaped-defect data as the reason. Frame it as buying down risk: 22 escapes in three months is a cost the current number hides.
Guardrails: every DoD change is agreed by the Scrum Team; the manager supports but does not impose; each change is reviewed at the Retrospective for whether it actually reduced escapes.