Purpose of a shared Definition of Done for multi-team products

WHAT THIS TESTS: The interviewer wants to know if you understand that Scrum is built on empiricism and that transparency is mandatory for inspection and adaptation to work. When multiple teams produce one product, the true state of the integrated Increment must be visible to everyone. If teams use different quality standards, the artifact has low transparency, which leads to decisions that diminish value and increase risk. The question reveals whether you treat the Increment as a single integrated body of work or merely a collection of team outputs.

A GOOD ANSWER COVERS: First, state that a shared standard creates transparency by making the done state of the integrated product visible to all Scrum Teams and stakeholders. Second, explain that this forces cross-team integration and validation within the Sprint so the resulting product is actually releasable, not just locally complete. Third, describe the impact on practices: teams must align their development and testing so that shared acceptance criteria are met before work is considered finished. Fourth, tie this back to empiricism: inspection of the Increment only works when everyone agrees what done means, and adaptation depends on an honest assessment of what was built.

COMMON WRONG ANSWERS: A major red flag is saying each team can define its own Done because they own different components. This fragments the Increment, hides integration debt, and makes inspection misleading. Another weak answer is describing Done as a documentation or sign-off checklist rather than a standard for the actual product. Saying the DoD is the Scrum Master's job to enforce is also wrong; the guide emphasizes the collective intelligence of the people using the framework, meaning the teams build and own the standard together.

LIKELY FOLLOW-UPS: The interviewer may ask how to handle a team that cannot meet the shared standard yet. They might ask what happens if integration testing takes longer than the Sprint. They may also probe whether the DoD can differ across products or must be identical across all teams in an organization.

ONE CONCRETE EXAMPLE: Imagine three teams building a mobile payment app. Team A finishes its feature and marks it done because its unit tests pass. Team B does the same. Without a shared Definition of Done, the integrated build fails because neither team performed end-to-end validation against the shared API. A shared DoD would require that every Increment meet integration thresholds before the Sprint ends, making the true state of the product transparent during the Sprint Review and allowing stakeholders to adapt based on the actual product.