Scaling Without a Shared Definition of Done
A company is scaling Scrum across four teams, all working on one product with a single Product Owner and a shared Product Backlog. Each team previously ran Scrum independently and has its own Definition of Done. Team A's DoD requires code review, automated tests, and deployment to production. Team B's requires code review and unit tests only. Team C's requires code review, integration tests, and sign-off from a security reviewer who is available two days per week. Team D's requires only that the code is merged. The teams now need to integrate their work every Sprint for a joint release. At the first joint Sprint Review, the integrated build failed: Team D's components had no tests, and Team C's security sign-off had not happened for three items. Each team considered its own work 'done'. There is also a newly formed fifth team that has been told to 'copy Team A's process'.
1. Analyse why the integration failed, and explain the role of the Definition of Done in a multi-team context.
Read the worked answer
Each team applied its own Definition of Done and each was locally correct; the failure is a system-level problem. When several teams contribute to one product Increment, 'done' must mean the same thing across the whole product, because the Increment is only as complete as its least complete component. Team D's merged-only DoD meant untested code entered the integrated build, and Team C's DoD depended on a part-time reviewer, making its definition of done contingent on a bottleneck rather than on the work being genuinely complete.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It creates shared transparency: anyone inspecting the Increment should be able to rely on 'done' meaning the same thing. With four different definitions, the joint Review inspected an Increment whose quality was unknown, which is precisely the transparency failure the artifact exists to prevent.
A key point is that the weaker definitions are not merely 'less rigorous' - they are inaccurate. Team D's DoD asserts completion that has not been verified. Team C's DoD is honest but creates a structural delay that the joint release plan did not account for. A shared DoD would have surfaced both problems before the Review.
2. The teams ask the Scrum Master to write a single Definition of Done for everyone. How should the Scrum Master respond, and what process should produce the shared DoD?
Read the worked answer
The Scrum Master should decline to author it unilaterally. A Definition of Done imposed from outside will not be owned, and the Scrum Master does not have the technical authority to decide what quality means for the product. The Scrum Master's role is to facilitate the conversation and ensure the outcome is genuinely shared.
A workable process:
- Bring the four teams and the Product Owner together and have each team present its current DoD and the reasoning behind it. This surfaces the real disagreements, such as whether security sign-off is mandatory and whether production deployment is required.
- Establish a minimum shared standard for the integrated product. This should be the strongest reasonable common denominator, not the weakest. If security sign-off is genuinely required for release, it belongs in the shared DoD, and the two-day-per-week reviewer becomes an impediment to be removed, not a reason to lower the standard.
- Agree how the shared DoD applies. Teams may add stricter practices locally, but no team may fall below the shared standard for work entering the integrated Increment.
- Make it visible and revisit it. Post it where all teams see it and review it at joint Retrospectives as capability improves.
For the fifth team, 'copy Team A's process' is a mistake: they should adopt the shared DoD and then develop their own practices. Copying another team's process without understanding it produces cargo-cult Scrum and skips the team's own learning.
3. What organisational impediments does this situation reveal, and how should the Scrum Master address them?
Read the worked answer
Three impediments stand out.
First, no shared quality standard across teams. This is the root cause of the failed integration. Addressing it through the shared DoD process removes it, but it also requires leadership agreement that the shared standard applies to all teams, which is beyond any single team's authority.
Second, the part-time security reviewer. A two-day-per-week specialist in the critical path of a Sprint means Team C cannot reliably meet any DoD that includes security sign-off. The Scrum Master should raise this as a capacity and dependency problem: either the review is automated or shifted earlier, or the specialist's availability increases, or security expertise is embedded in the teams. Leaving it unaddressed guarantees recurring delay no matter what the DoD says.
Third, the fifth team's onboarding by copying. This suggests the organisation treats process as something to replicate rather than something teams develop. The Scrum Master should offer the new team facilitation and coaching so they build their own way of working on top of the shared standard.
In each case the Scrum Master's approach is the same: make the impediment visible with evidence from the failed Review, facilitate the decision among those with authority, and follow up until it is resolved or escalated. The Scrum Master does not fix these alone; they ensure they get fixed.