Definition of Done: Quality Commitment that Enables Transparency

Definition

The Definition of Done is a formal, shared standard that describes the complete state of an Increment when it meets all quality measures required for the product. It is not aspirational; work that does not meet the Definition of Done cannot be presented at a Sprint Review or released. The Definition of Done creates transparency by providing everyone—developers, product owner, stakeholders—a single, agreed baseline for what "complete" actually means.

In the Book

The 2020 guide states: "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born." The guide emphasizes its transparency function: "The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment."

The guide also clarifies what happens when it is violated: "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration." It further notes that the Definition of Done may come from organizational standards (in which case all teams must follow the minimum) or be created by individual teams if no organizational standard exists. Critically: "The Developers are required to conform to the Definition of Done."

Why It Matters

Without a Definition of Done, teams and stakeholders disagree silently about what "done" means. One person thinks "code complete"; another thinks "tested in production." This hidden disagreement becomes visible only when the increment fails, and then blame flows toward whoever had the stricter standard. The Definition of Done is not bureaucracy—it is the guard rail that makes inspection honest. When a team truly holds a Definition of Done, velocity becomes meaningful (it measures real completeness, not wishful counting), retrospectives become actionable (quality problems have a named location to fix), and trust between team and stakeholders solidifies. In knowledge work, where "done" is abstract, explicit shared criteria are the only way to keep empiricism from devolving into opinion.