What the Definition of Done actually governs
The Definition of Done creates transparency by giving everyone shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released and cannot even be presented at Sprint Review as finished; it returns to the Product Backlog for future consideration.
Where an organization has its own standards, the Scrum Guide says those are followed as a minimum, and Scrum Teams add to them as appropriate for the product. Where no organizational standard exists, the Scrum Team itself must create a Definition of Done suitable for the product.
Who owns it and how it gets built
The Definition of Done belongs to the whole Scrum Team, not just the Developers or a QA function bolted onto the end. Developers are required to conform to it when creating each Increment, and it is meant to be inspected and adapted like any other part of Scrum, most naturally in the Sprint Retrospective.
A realistic Definition of Done usually includes things like code reviewed, automated tests passing, documentation updated, and accessibility or security checks completed, tailored to whatever the product actually needs. It should be strict enough to mean something and specific enough that two different people would agree whether an item meets it.
- Written down and visible, not tribal knowledge in one person's head
- Owned by the whole Scrum Team, including the Product Owner
- At least as strict as organizational standards, where they exist
- Revisited in the Sprint Retrospective as the product matures
Raising the bar over time
As a Scrum Team matures, its Definition of Done is expected to expand to include more stringent criteria for higher quality. A team that starts with 'code merged and manually tested' might evolve toward automated regression coverage, performance budgets, and accessibility checks as the product and its risks grow.
This evolution should be deliberate, discussed and agreed by the team, not silently skipped when the Sprint is tight. Cutting corners on the Definition of Done under deadline pressure is exactly the failure mode it exists to prevent.
Anti-patterns
The most damaging anti-pattern is a Definition of Done that exists on paper but is quietly ignored when the Sprint is behind, which produces a growing pile of undisclosed technical debt behind a Increment that only looks finished. Another is a Definition of Done so vague it cannot be checked, such as 'code is good,' which provides no real quality gate at all.
A third is confusing the Definition of Done with the acceptance criteria of an individual Product Backlog item; acceptance criteria describe what a specific item must do, while the Definition of Done describes the quality bar every item must clear regardless of what it does.
How it connects to the rest of Scrum
The Definition of Done determines what can honestly be shown at Sprint Review, and it is one of the explicit topics the Sprint Retrospective is allowed to revisit and change. It also underpins the Product Increment itself, since the Scrum Guide defines an Increment as existing only once its Product Backlog item meets the Definition of Done.
Frequently asked questions
Is the Definition of Done the same as acceptance criteria?
No. Acceptance criteria describe what a specific Product Backlog item must do to be considered correct. The Definition of Done is a broader quality standard that applies to every item regardless of its content, covering things like testing, review and documentation.
Who creates the Definition of Done?
The Scrum Team creates it, following any organizational standards as a minimum. There is no separate quality role that owns it in the Scrum Guide; Developers, the Product Owner and the Scrum Master all share responsibility for maintaining and honoring it.
What happens to a Product Backlog item that does not meet the Definition of Done?
It is not considered an Increment and cannot be released or presented as finished at Sprint Review. The Scrum Guide states it returns to the Product Backlog for future consideration rather than being counted toward the Sprint's completed work.
Can the Definition of Done change over time?
Yes, and the Scrum Guide expects it to. As a team matures, its Definition of Done is expected to expand to include more stringent criteria for higher quality, and the Sprint Retrospective is an explicit place to reconsider it.