Acceptance Criteria vs Definition of Done: What Each One Is For

Introduction

Two checklists govern whether a piece of work is finished, and teams mix them up constantly. Acceptance criteria say whether this story does what it was supposed to do. The Definition of Done says whether any work is in a state fit to ship.

The confusion is expensive in both directions. Teams that treat them as one thing either copy "tests written, code reviewed, docs updated" into every ticket, which nobody reads by the third sprint, or they leave quality rules out of every ticket on the assumption they live somewhere else — and nobody can say where.

The difference in one table

A one-line way to keep them apart: acceptance criteria are about behaviour, the Definition of Done is about quality. "The discount applies to orders over 50 EUR" is behaviour. "The change has a test that would fail without it" is quality.

Acceptance criteria: one story at a time

Acceptance criteria describe the conditions this particular story has to satisfy. They change with every story, because every story does something different, and they are written before the work starts so that the developer and the tester are building and checking the same thing.

They are the product owner's starting point, though the common practice is to write them with a developer and a tester in the room. What makes one usable is covered in detail in how to write acceptance criteria a tester can't misread: name the role, make every criterion observable, put a number on every limit, and describe the paths that are not the happy one.

The Definition of Done: every story, every time

The Definition of Done is a shared standard for what "shippable" means on this product. The Scrum Guide calls it a formal description of the Increment's state when it meets the product's quality measures — one description, applying to everything the team produces.

Three things follow from that, and they are the reason the Definition of Done has teeth:

• It is not negotiable per story. If it were, it would be acceptance criteria.
• Work that does not meet it cannot be released, or even shown at Sprint Review. The Scrum Guide says such an item returns to the Product Backlog.
• Where the organisation sets a standard, that standard is the floor. Teams can be stricter than it, never looser.

The last point is what makes a Definition of Done useful across teams: it is the thing a product owner can rely on without inspecting anyone's pull requests.

Who owns which

The product owner is accountable for the Product Backlog being clear and understood, which puts acceptance criteria squarely in their remit — the Scrum Guide allows them to delegate the writing while keeping the accountability.

The Definition of Done is different. The developers conform to it, and the team owns it, with the organisation setting the minimum where one exists. A product owner cannot waive it for a story that is running late. That constraint is a feature: it is precisely the pressure point where quality is usually traded away, and putting the decision outside the negotiation is the point.

What a product owner can do is push for the Definition of Done to be revisited between sprints, as a standing conversation rather than an exception granted under deadline.

What belongs in a Definition of Done

A workable Definition of Done is short, applies to everything, and is mostly checkable by a machine. A realistic starting set:

• The change has an automated test that fails without it, and the suite passes in CI.
• Code has been reviewed by someone who did not write it.
• No new linter, type, or accessibility violations — see accessibility testing with axe and the keyboard.
• New or changed behaviour that users see is documented where users will look.
• Feature flags default to off, and the change is deployable without a manual step.
• No known defect of severity Major or above is left open against the work.
• Observability: the new path emits whatever the team needs to tell whether it is working in production.

Seven lines is plenty. A Definition of Done that runs to thirty items is one nobody reads, which makes it decorative.

What doesn't belong

• Anything specific to one story. "The CSV includes a totals row" is an acceptance criterion. If it is in the Definition of Done, the Definition of Done is being used as a backlog.
• Anything nobody checks. An item nobody verifies trains the team to treat the whole list as optional.
• Anything outside the team's control. "Signed off by the VP" is a release gate, not a Definition of Done; it belongs in a go/no-go decision instead.
• Aspirations. "Code is clean" cannot pass or fail, and the same rule that kills it in a story kills it here.

When a story meets its criteria but not the Definition of Done

This is the case worth recognising on sight, because it is the one that gets argued about at review.

A story says an expired card must show a specific message and disable the Pay button. The developer builds exactly that, and it works when demonstrated. The change has no test, and the accessibility check reports the new error message is not announced to screen readers.

Every acceptance criterion is met. The work is not done. It cannot be released and, by the Scrum Guide's rule, should not be presented at Sprint Review; it returns to the backlog. In practice, teams that skip this conversation accumulate a category of work that is "finished" but keeps coming back, which is how a velocity number and a release date drift apart.

The reverse case exists too and is less contentious: work that clears every quality bar and does the wrong thing. That is an acceptance criteria problem, and usually a sign the criteria were written alone.

Make the Definition of Done enforceable

A Definition of Done that lives on a wiki page is a statement of intent. Most of its items can be checks that run on every pull request, and the ones that can be, should be:

Two items on that list still need a human, and that is fine. The goal is not to automate judgement; it is to stop spending judgement on things a pipeline can decide. Integrating tests into CI/CD covers the mechanics of making those checks blocking rather than advisory.

Common mistakes

• Quality rules copied into every story. The clue is the same three bullets at the bottom of every ticket. Move them to the Definition of Done and delete them from the stories.
• A Definition of Done with no checks behind it. If nothing fails when an item is skipped, it is not a rule.
• Waiving it under deadline. Once it has been waived, it is a suggestion. The honest alternative is to reduce the scope of the release, not the standard of the work.
• Never revisiting it. As the team's tooling improves, items that were aspirational become automatic. A Definition of Done that has not changed in two years is describing a team that no longer exists.
• Confusing it with release criteria. The Definition of Done says the work is shippable. Whether to ship it on Thursday is a separate decision with its own evidence.

Conclusion

Acceptance criteria answer whether this story does what was asked. The Definition of Done answers whether any work is fit to ship. Keeping them separate stops quality rules from being retyped into every ticket, and stops them from quietly going missing.

The practical test for a product owner: if you found yourself writing the same bullet into a third story this month, it belongs in the Definition of Done. If you found yourself waiving a Definition of Done item to hit a date, the thing to change is the scope of the release, not the standard.

For the story-level half, use the acceptance criteria grader and how to write acceptance criteria a tester can't misread. For the release decision that comes after both, see go or no-go.

Sources and further reading

• The Scrum Guide: Definition of Done, Increment, and the Product Owner's accountabilities
• TechTarget: how to compare acceptance criteria vs. definition of done
• Atlassian: what is acceptance criteria?
• Scrum.org: self-managing defects escaping into production