Definition of Done Versus the Release Train
A team of six Developers works on a regulated insurance claims product. Their Definition of Done requires automated regression tests, a security review, and sign-off from a compliance officer before an item counts as done. Compliance sign-off currently takes 8–12 working days. The team's velocity has dropped 40% over two Sprints because items pile up in 'done but not signed off.' The Product Owner wants to relax the Definition of Done to 'code complete and unit tested' so the Sprint Review shows more completed work. The compliance officer says the review is non-negotiable for anything customer-facing. The Sprint is 10 working days. Two items have been waiting 14 days for sign-off.
1. Should the team relax the Definition of Done? Explain using the relationship between the Definition of Done and the Increment.
Read the worked answer
No - not by redefining 'done' to exclude a required quality gate. The Definition of Done is the team's shared commitment about what it means for work to be part of a usable Increment. If compliance sign-off is genuinely required for customer-facing work, removing it from the DoD doesn't make the work done; it makes the Increment's transparency false, and the team will report progress that cannot be released.
The PO's underlying need is real: the Sprint Review should show inspectable value. But the fix is to shorten the path to done, not to lower the bar. A Definition of Done that the organization cannot actually meet in a Sprint is a signal to change the system, not the definition.
2. What options does the Scrum Master have to shorten the 8–12 day sign-off without weakening the Definition of Done?
Read the worked answer
Treat the sign-off delay as an impediment to the Definition of Done and work the system:
- Shift left: involve compliance earlier - e.g., a short review of the security-relevant design before coding, so the final sign-off is confirmation rather than discovery.
- Reduce batch size: smaller, more frequent submissions may get faster turnaround than large ones; ask the compliance officer what makes review slow.
- Make the wait visible: chart time-in-sign-off so the organization sees the 14-day queue as a systemic cost, not a team failure.
- Negotiate the gate itself: the SM can facilitate a conversation between the PO and compliance about which items truly require sign-off before release versus before general availability.
The SM does not decide compliance policy. The SM makes the cost visible and helps the people who own the policy change it.
3. The PO insists on showing 'code complete' items at the Sprint Review. How should the Scrum Master handle this?
Read the worked answer
Distinguish inspection from misrepresentation. It is fine - often valuable - to show work in progress and unfinished items at the Review, as long as it is clearly labeled as not done and the stakeholders understand it cannot be released. It is not fine to count those items as completed or to present them as part of the Increment.
The SM should coach the PO to frame the Review around the Sprint Goal and the Product Goal: what did we achieve, what did we learn, what should we do next - including honest discussion of the sign-off bottleneck. If the PO's real fear is that executives will judge the team on a low count, the SM should help make the systemic constraint visible to those executives rather than hide it behind a redefined DoD.