What is the Definition of Done (DoD)?

WHAT THIS TESTS: This question assesses your understanding of a core Scrum artifact commitment. The interviewer wants to see if you can move beyond a simple definition and explain WHY the DoD is critical for empiricism (transparency, inspection, adaptation). For a senior role, they're testing if you see it as a key lever for managing quality, reducing risk, and enabling predictable delivery of value, not just a process step.

A GOOD ANSWER COVERS: A strong answer will cover four points. First, define the DoD as the formal, shared commitment to the quality standard for the Increment, making it potentially releasable. Second, explain that it creates transparency; everyone (developers, Product Owner, stakeholders) knows exactly what 'done' means. Third, link this transparency to predictability. When 'done' is consistent, the team can more accurately forecast future work and stakeholders can trust the Increment's state. Fourth, connect it to quality. A robust DoD that includes testing, documentation, and non-functional requirements prevents technical debt and ensures each Increment is genuinely usable.

COMMON WRONG ANSWERS: A weak answer treats the DoD as a simple checklist, often just "code complete and unit tests passed." This is a major red flag. Another mistake is confusing the Definition of Done (which applies to the entire Increment) with Acceptance Criteria (which are specific to a Product Backlog Item). A senior candidate must articulate this difference. Finally, answers that describe the DoD as something imposed on the team, rather than created and owned by the Scrum Team, miss the point about commitment and collective ownership.

LIKELY FOLLOW-UPS: "Who is responsible for creating and maintaining the DoD?" (The Scrum Team). "What happens if a team can't meet its DoD for an item in a Sprint?" (The work is not 'done' and cannot be part of the Increment; it returns to the Product Backlog). "How might a DoD evolve over time?" (It should become more stringent as the team and product mature, incorporating more advanced quality checks).

ONE CONCRETE EXAMPLE: A team's initial DoD might be "code peer-reviewed, unit tests at 80% coverage, and QA passed on staging." After a production incident, they might strengthen their DoD to include "performance tests run, security scan passed, and user documentation updated." This change directly improves the quality and reduces the risk of future Increments. It makes their velocity more predictable because "done" now includes activities that were previously causing unforeseen rework.