What is the purpose of a shared 'Definition of Done'?

WHAT THIS TESTS: This question assesses your understanding of how to maintain product quality and transparency when scaling Scrum beyond a single team. The interviewer wants to see if you can think at the product level, not just the team level. It specifically tests your knowledge of the 'Increment' as a core Scrum artifact and how a shared Definition of Done (DoD) is the key commitment that ensures a single, integrated, usable product is created each Sprint from the work of many teams.

A GOOD ANSWER COVERS: First, define it as a formal, shared agreement on the quality standards that work must meet to be considered part of the integrated product Increment. Second, explain its primary purpose: to ensure that the work from all teams combines into a single, usable, and potentially releasable product version at the end of every Sprint. This creates transparency for all stakeholders. Third, detail its impact on development practices, such as forcing the use of shared repositories, continuous integration (CI), and common standards. Fourth, explain its impact on testing, requiring integration, end-to-end, and non-functional tests (e.g., performance) to be part of every team's responsibility within the Sprint, not a later phase.

COMMON WRONG ANSWERS: A major red flag is describing a scenario where each team has its own, independent DoD. While a team can add to the shared DoD, they must meet the baseline for the product. Saying "each team decides what 'done' means" shows a failure to understand integration. Another mistake is treating the DoD as a simple task checklist (code written, PR approved) instead of a commitment to the quality and state of the integrated Increment. Finally, suggesting that integration happens in a separate "integration sprint" is incorrect; a shared DoD implies integration is a continuous activity for all teams.

LIKELY FOLLOW-UPS: Expect questions like, "How would you facilitate the creation of a shared DoD among several teams?" or "What happens if one team consistently fails to meet the shared DoD?" For the latter, a good answer explains this is a critical impediment for the Scrum Masters to address, as it threatens the value of the entire Sprint for all teams. It requires immediate inspection and adaptation.

ONE CONCRETE EXAMPLE: For a mobile app built by four teams, our shared DoD required every code merge to the main branch to pass a full suite of integration tests and not increase the app's startup time by more than 5ms. This meant a feature wasn't 'done' when it worked in isolation. My team had to work with the platform team to run performance profiling in a shared staging environment before we could consider our user story complete. This prevented end-of-sprint surprises where the integrated app was too slow to ship.