Definition of done
A definition of done is the shared, written checklist of conditions that every piece of work must satisfy before the team calls it complete: for example code reviewed, tests passing, deployed to staging, documentation updated, no open bugs. It applies to all work items equally, unlike acceptance criteria, which are specific to one story. Work that does not meet every condition is not done, whatever its ticket says.
The longer version
The checklist exists so that done means the same thing to everyone: a developer who says a story is finished, a tester who picks it up, and a product owner who plans the next sprint around it. Without one, done means code committed to one person, tested to another and released to a third, and the gap between those meanings is where work silently piles up before a release. A team's definition is written once, kept short enough to check against, and applied to every story, bug fix and task alike. It is a quality gate rather than a description of the work.
Acceptance criteria are the nearest neighbour and the common confusion. Criteria are written per story and say what that story must do; the definition of done is written per team and says what every story must have been through. A story can satisfy every criterion and still not be done because nobody reviewed the code, and it can pass every gate in the definition while doing the wrong thing. The two checks are independent, and a story passes both or is not finished.
A definition decays into an aspirational list nobody can meet or a thin one that gates nothing. The aspirational list reads performance tested, accessibility audited, localised, security reviewed, for a team that has no one to do half of those, so it is quietly ignored and done goes back to meaning whatever the developer meant. The thin list reads code merged, ticket closed. The useful definition is the one the team actually checks, which usually means a handful of conditions with a named person or an automated check behind each. Bugs found in testing against a story that was already called done are the evidence the definition is not being applied.
Common questions
What is the difference between definition of done and acceptance criteria?
Acceptance criteria belong to one story and say what it must do, while the definition of done belongs to the team and lists what every story must have been through before it counts as complete, and a story passes both or is not finished.
Who owns the definition of done?
The whole delivery team, with the developers and testers who have to meet it writing it and the product owner agreeing to it. In Scrum the definition is the team's commitment for every increment; where the organisation sets a minimum definition, every team must meet it and may extend it. A definition nobody on the team helped write is the one most likely to be skipped.
What should a definition of done include?
Conditions the team can check on every item: code reviewed, automated tests written and passing, acceptance criteria verified by the product owner, deployed to a staging environment, no open bugs against the work, and any documentation or release note updated. Keep it to the conditions the team will enforce; an unenforced condition weakens the rest.
When is the definition of done applied?
At the moment a story, bug fix or task is about to be called complete, which in most teams is when the developer moves the ticket to its final column and again when the tester or reviewer accepts it. In Scrum it is also checked for the whole increment before the sprint review, so that nothing shown as finished is missing a gate. A definition consulted only at the retrospective is a summary rather than a standard.
What happens when a story does not meet the definition of done?
The story is not done, whatever its ticket says, and it goes back to in progress until every condition holds: unreviewed code gets reviewed, a missing test gets written, a deployment to staging is made. In a sprint it is not counted as finished and is not presented as complete; under the Scrum Guide it returns to the Product Backlog, where the product owner decides whether it is picked up again. Waiving a condition for one story teaches everyone that the definition is optional.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.