Definition of Done vs Acceptance Criteria: What's the Difference?

Every Scrum team uses both — but most teams couldn't clearly explain where one ends and the other begins. Definition of Done and Acceptance Criteria are both gates that a user story must pass before it's considered complete, and that overlap is exactly what causes the confusion. They look similar from the outside. But they answer completely different questions, they're owned by different people, and conflating them creates a specific, recurring class of quality problem that's expensive to fix once it's established as a team habit.

This guide draws the line clearly: what each one is, who owns it, how to write it well, and what goes wrong when teams mix them up. There's also a third checklist — the Definition of Ready — that most teams discover too late, usually after they've already suffered the problem it prevents.

Why the Confusion Exists — and Why It Matters

Both DoD and AC answer the question "is this story done?" Which means both look like checklists for completeness, and teams treat them as interchangeable. The most common symptom: teams include DoD items in their Acceptance Criteria. "Code reviewed" appears as an AC item. "No high-severity bugs" gets written into every story's requirements. "Deployed to staging" shows up in the list alongside actual functional behavior.

This feels harmless — the information is there somewhere, so who cares where? — but it creates compounding problems:

• When the DoD evolves (and it should), stories with DoD items buried in their AC don't get updated. You now have inconsistent standards across the backlog.
• Stories without that specific AC item look like they don't require code review. A new team member reads the AC and assumes the standard doesn't apply.
• Product owners writing AC start including engineering quality requirements — which is outside their domain and creates friction with developers who know the AC is specifying implementation rather than behavior.
• The real DoD never gets written down, which means it exists only in the heads of senior team members — invisible to new joiners and impossible to hold the team accountable to.

"The Definition of Done is how the team prevents technical debt from accumulating silently. Acceptance Criteria is how the product owner prevents feature drift. Both are necessary. Neither substitutes for the other."

What Is the Definition of Done?

The Definition of Done is a shared team checklist that specifies what must be true for any user story to be considered complete and potentially shippable — regardless of what the story is about. It's the team's minimum quality bar, applied consistently to every piece of work that enters and exits a sprint.

A well-written DoD makes these guarantees to the organization:

• Any story marked Done has code that was reviewed by at least one other engineer
• Any story marked Done has tests that pass and no new high-severity issues
• Any story marked Done can be deployed — it's not waiting on manual steps, credentials, or environment setup
• Any story marked Done has documentation current enough that another engineer could maintain it

The DoD is owned by the Developers (called the "Development Team" in older Scrum terminology). The Scrum Master facilitates and coaches its use. The Product Owner doesn't set the DoD — they set Acceptance Criteria. This distinction matters because DoD items are engineering quality decisions that require engineering expertise to define and evaluate.

What typically goes in a DoD

What Are Acceptance Criteria?

Acceptance Criteria are the specific conditions a user story must satisfy for the Product Owner to accept the story as meeting the user's need. Unlike the DoD — which is the same for every story — AC is unique to each story and describes the functional behavior the feature should exhibit.

AC is written from the user's perspective, not the engineer's. It describes what the system does, not how it does it. The Product Owner owns AC — they define what "done" means for this specific requirement. Developers and QA provide input (especially on edge cases), but the product owner has the final say on whether AC captures the intent correctly.

The most structured format for writing AC is Given/When/Then (Gherkin syntax), which maps directly to automated test structure:

Notice what's not in the AC above: code review, test coverage, deployment environment — those belong in the DoD and apply automatically to this story alongside every other story in the sprint. The AC only specifies what the login feature does from the user's point of view.

The foundation of good AC is a well-formed user story to begin with. See our full guide on how to write user stories for the format and patterns that produce AC-ready stories from the start.

The Key Differences Side by Side

The practical test: if the item applies to every story regardless of what the story is about — it belongs in the DoD. If the item is specific to this particular story's behavior — it belongs in the AC. "Code reviewed" applies to every story → DoD. "Users can reset their password via email link" only applies to the password reset story → AC.

What Breaks When You Mix Them Up

The failure modes from conflating DoD and AC are predictable. Here are the four most common:

1. The DoD never gets written

If teams put quality items in every story's AC, the DoD never needs to be articulated — it's implicitly encoded across hundreds of stories. The problem: it only exists in the stories the team has already written. New stories don't automatically inherit it. New team members don't see it. The quality standard exists but isn't legible as a standard — it's just a pattern scattered across the backlog.

2. Inconsistent quality across stories

If code review is an AC item on some stories but not others, a strict reading of the process means code review is optional for stories without that AC. In practice, experienced developers apply it anyway. But "apply it anyway" is tribal knowledge — it doesn't survive team turnover or growth.

3. The PO starts setting engineering standards

When the PO writes AC that includes quality requirements ("must have 90% test coverage", "must be reviewed before merging"), they're reaching into engineering decisions they don't have the context to make correctly. "90% test coverage" on a story that touches business logic might be the right standard; on a story that's pure UI rendering, it's pointless. DoD items are engineering decisions — they belong with the people who have the context to set them correctly.

4. Refinement gets confused with DoD validation

Sprint review becomes a muddled exercise when teams don't clearly separate "does this meet the DoD" (engineering question) from "does this meet the AC" (product question). In a healthy sprint review, the PO validates AC against the demo. The DoD check happens before the story even reaches the review — it's the team's internal gate, not a stakeholder gate.

How to Build a Strong Definition of Done

Building a DoD is a team exercise, not a document the Scrum Master writes alone. Run it as a workshop in a sprint retrospective — most teams that don't have one can draft their first version in 45 minutes.

1. List everything that must be true for a story to be shippable — each person on the team writes their own list first, independently, then the team compares. Independent generation prevents anchoring and surfaces items people assumed were obvious but weren't explicitly shared.
2. Group by type — code quality, testing, deployment, documentation, design, security. This naturally reveals categories where the team has implicit standards but hasn't formalized them.
3. Narrow to what you can commit to on every story. Everything on the DoD applies to every story — so anything that's "usually but not always" needs to either become mandatory or be removed. "Sometimes" isn't a DoD standard, it's a guideline.
4. Make it visible. Post it on the sprint board, include it in the team working agreement, reference it in sprint planning. The DoD only functions as a quality gate if people encounter it constantly.
5. Review it every retrospective. Specifically ask: "Did any stories almost fail the DoD this sprint?" and "Are there categories of defect that escaped because our DoD didn't cover them?" Evolve it based on evidence, not theory.

Writing Acceptance Criteria That Developers Can Actually Use

Good AC is testable, behavior-focused, and complete without being prescriptive about implementation. Here's the difference in practice:

Each AC item should be answerable with a clear yes or no. If you can't write a test — automated or manual — against an AC item, it's too vague. "Loads quickly" is not testable. "First Contentful Paint under 1.5 seconds on a simulated 4G connection" is testable and deterministic.

Cover the error paths, not just the happy path

First drafts of AC almost always describe what happens when everything works. Strong AC also covers: what happens when the user provides invalid input, what happens when the network fails mid-operation, what happens when a downstream service is unavailable, and what happens when the user has insufficient permissions. These edge cases are where product decisions are actually made — and if they're not in the AC, developers will make them unilaterally, often in ways the PO wouldn't have chosen.

Reviewing your estimation accuracy against AC coverage is a useful retrospective exercise. If stories frequently have late-discovered edge cases, your AC is likely missing error paths. See our sprint retrospective templates for formats that surface this kind of estimation and scope mismatch systematically.

The Third Checklist Teams Forget: Definition of Ready

The Definition of Ready (DoR) is the inverse of the DoD — it specifies what must be true for a user story to be ready to be pulled into a sprint. It's the input quality gate, where DoD is the output quality gate.

Teams without a DoR pull half-formed stories into sprints and discover mid-sprint that the requirements aren't clear enough to build against. The story either stalls, gets done wrong, or gets pushed to the next sprint — all forms of waste. The DoR prevents this by making "ready to build" an explicit standard, not an assumption.

The DoR isn't part of the Scrum Guide — it's a pattern that experienced teams adopt after experiencing the problem it solves. It's especially valuable for teams where backlog refinement happens inconsistently, or where the PO is stretched across multiple teams and stories sometimes enter sprints under-specified.

All three artifacts — DoD, AC, and DoR — are inputs to the estimation conversation. A story without complete AC shouldn't be estimated; a story that won't pass the DoD as written is over-scoped for the sprint. For the full estimation picture, see our guide on story points vs hours.