Acceptance criteria vs Definition of Done at a glance
Both are checklists, which is why they get mixed up. The difference is what they apply to, who owns them and when they’re written.
- Scope: acceptance criteria are unique to one story. The Definition of Done applies to every backlog item and to the Increment as a whole.
- Owner: the product owner usually writes acceptance criteria with the team. The Scrum Team creates the Definition of Done, unless the organization already sets one as a standard.
- Timing: acceptance criteria are written for each story during refinement. The Definition of Done is set once and revisited, often in a retrospective.
- Focus: acceptance criteria describe functional behavior. The Definition of Done describes quality and process, such as testing, review and documentation.
- Who checks: the product owner accepts a story against its criteria. Developers must meet the Definition of Done before calling any item done.
- Change rate: every story gets new criteria. The Definition of Done changes rarely, and teams often tighten it as they mature.
What the Definition of Done means in Scrum
The 2020 Scrum Guide treats the Definition of Done as the formal quality bar an Increment has to meet. It’s the commitment for the Increment, in the same way the Product Goal is the commitment for the Product Backlog and the Sprint Goal is the commitment for the Sprint Backlog.
Work that falls short of it can’t be released or shown at the Sprint Review; it goes back to the Product Backlog. Acceptance criteria don’t appear in the Scrum Guide at all. They’re a widely used practice that fits inside it.
Examples of each
For a story like “As an admin, I can export the audit log to CSV,” the two lists look very different:
- Acceptance criterion: the export includes every event in the selected date range.
- Acceptance criterion: each row shows the timestamp, actor, action and target.
- Acceptance criterion: exports over 100,000 rows are emailed as a link.
- Definition of Done: code reviewed and merged to the main branch.
- Definition of Done: unit and integration tests written and passing in CI.
- Definition of Done: no new high-severity security findings.
- Definition of Done: deployed to staging, with release notes updated.
Where the Definition of Ready fits
A Definition of Ready is an optional checklist for when a story can be pulled into a sprint. It might require acceptance criteria, an estimate and no open blockers. It isn’t part of the Scrum Guide, which only says items are ready for selection when they’re clear and small enough to be done within one sprint.
In order: the Definition of Ready gates the start, acceptance criteria define the target, and the Definition of Done gates the finish. Keep a Definition of Ready light. If it turns into a long sign-off, it slows the very conversations stories are meant to start.
Who creates the Definition of Done
If the organization has a Definition of Done as a standard, every Scrum Team uses it as the minimum and can add to it. If not, the Scrum Team creates one that fits its product. When several teams work on the same product, they share one Definition of Done.
In practice, write it with the whole team, keep it short enough to check at a glance, and revisit it in a retrospective whenever a quality problem slips through.
Acceptance criteria vs DoD in NoaBox
NoaBox doesn’t have a built-in Definition of Done feature. You can keep yours on a page inside the project, next to the work it applies to. For acceptance criteria, Noa drafts them on each proposed work item when you attach a PRD, spreadsheet or CSV in Ask Noa.
See Pages and docs