Done Means Done: Building a Definition of Done With Teeth
In Scrum, the Definition of Done is the shared, formal description of the state an Increment must reach to be considered usable. The 2020 Scrum Guide is blunt about it: when a Product Backlog item meets the Definition of Done, an Increment is born, and work that does not meet it cannot be released or even presented at the Sprint Review. The trouble is that many teams write a Definition of Done so soft it certifies nothing. "Code complete" and "tested" sound rigorous until you ask what they actually require. This is a checklist for building one with teeth — and for using it honestly.
What a real Definition of Done requires
A Definition of Done with teeth is verifiable, not aspirational. Every line should be something a Developer can point to and say "yes, that happened" without interpretation. Use the checks below to pressure-test yours.
Every item is binary. "Tested" is an opinion; "all acceptance tests pass in the build pipeline" is a fact. Rewrite each criterion until it has an unambiguous yes or no answer.
It covers the whole increment, not one task. Done applies to a usable Increment, so include integration, not just isolated coding. If a feature works only on a developer's laptop, it is not done.
Quality is built in, not bolted on. Name the standards explicitly — code review, automated test thresholds, security and accessibility checks — so quality is a gate, not a hope.
It reflects the real release path. If a regulated or public-sector deployment needs documentation, sign-offs, or an audit trail, those belong in the Definition of Done, because without them the work cannot actually ship.
It is owned by the whole Scrum Team. The Developers commit to it, but the Product Owner and Scrum Master must understand it, because it governs what can be reviewed and released.
Nothing leaves the sprint half-done. Work that does not meet the Definition of Done returns to the Product Backlog; it is never partially credited as complete in the Increment.
Using it this sprint
A Definition of Done only has teeth if the team uses it as a gate during the Sprint, not as a memory after it. The practical moves are small but they change behaviour. In 2022, with distributed and hybrid teams the norm, a written, shared Definition of Done also does quiet work that hallway conversations used to do — it keeps a remote team aligned on what "finished" means without anyone having to ask.
Read the Definition of Done aloud when refining items, so the team estimates the real cost of done.
Treat it as a checklist at the moment a Product Backlog item is claimed complete, before it counts toward the Increment.
At the Sprint Review, only present work that genuinely meets it — do not demo aspirations.
Inspect and adapt the Definition itself at the Retrospective; tighten it as the team's capability grows.
When the bar is too high to reach yet
Sometimes a team cannot yet meet every criterion an organization needs — perhaps automated deployment or full security testing is not in place. The Scrum Guide's guidance is not to lower the bar but to make the gap visible: the Definition of Done captures the standard the organization requires, and any criteria the team cannot yet satisfy become known work to build that capability. A weaker Definition of Done hides risk; an honest one that the team is still growing into surfaces it. The goal is never a Definition that is easy to pass, but one that means something the moment it is passed.
If your teams need help turning a vague Definition of Done into a verifiable quality gate — and wiring it into how work is reviewed and released — XNM's program & project delivery advisory can help you make done actually mean done.