Definition of Done vs Acceptance Criteria

Definition of Done (DoD) and acceptance criteria are both about completion, but they apply at different levels. Confusing them creates duplication (the same check appears in every story's criteria) or gaps (something important isn't anywhere). Used cleanly, they cover completion comprehensively without redundancy.

The Distinction

Definition of Done is team-wide and story-agnostic. It defines the baseline every story must meet. "Tested. Reviewed. Deployed. Documented." Same for every story.

Acceptance criteria are story-specific. They define when this particular story's intent is met. "Workspace switcher shows all workspaces the user has access to."

A story is done when both are satisfied. The DoD applies to all stories; the criteria apply to this one.

What Goes in Definition of Done

The DoD typically covers:

• Code committed and merged

• Code reviewed

• Unit tests written and passing

• Integration tests passing

• Documentation updated where relevant

• Deployed to the appropriate environment

• Acceptance criteria verified

• No new accessibility regressions

• No new security vulnerabilities introduced

• Metrics or analytics added if relevant

• Monitoring/alerting updated if relevant

The specifics depend on the team. The principle: things that should be true for every story.

What Goes in Acceptance Criteria

Acceptance criteria cover:

• The specific behaviors this story should produce

• The specific conditions and outcomes

• Edge cases relevant to this story

Acceptance criteria don't repeat DoD items. "Tests written" isn't an acceptance criterion (it's in DoD). "User can switch workspaces" is.

Why Mixing Them Creates Problems

When teams put DoD-style items in every story's acceptance criteria:

• Stories are cluttered with the same boilerplate

• Important DoD items vary across stories (some have "tests written," some don't)

• The DoD baseline isn't really enforced

• Story refinement takes longer than needed

When teams omit a DoD entirely and put everything in acceptance criteria:

• Inconsistency across stories

• Story authors decide what's required, not the team

• No baseline guarantee

The separation is what produces consistent quality.

Building the Definition of Done

The DoD is a team agreement. Build it explicitly:

1. The team discusses what should be true for every story

2. Each item is debated: is this really baseline?

3. The list is agreed upon

4. The DoD is visible (on the wiki, in the team channel, on a wall)

Update the DoD when the team's standards change. New testing requirements. New compliance needs. Tooling improvements.

DoD Levels

Different scopes can have different DoDs:

• Story-level DoD: what's true when a story is done

• Sprint-level DoD: what's true when the sprint is over

• Release-level DoD: what's true when the release ships

Story-level is the most common and most important. The others appear in mature teams that ship in larger batches.

Common DoD Items

A working DoD for a typical web product team:

• Code merged to main

• At least one reviewer approved

• Unit tests added/updated; full suite passing

• Integration tests passing

• No new linter or type errors

• Accessibility check passing

• Documentation updated (README, API docs, internal wiki)

• Feature flag or rollout plan documented if applicable

• Deployed to staging

• PM acceptance test signed off

About 10 items. Specific to the team's process.

Avoid Over-Including

Tempting items that shouldn't be in DoD:

"User testing completed." Doesn't apply to every story.

"Performance validated." Doesn't apply to every story.

"Compliance review." Only for stories that need it.

"Stakeholder presented." Not appropriate baseline.

If something doesn't apply universally, it's not DoD; it's a per-story acceptance criterion.

Updating the DoD

The DoD should evolve. Triggers:

• New testing capability (add to DoD)

• Recurring quality issue (add a check)

• New compliance requirement (add it)

• Process change (modify accordingly)

A DoD that hasn't changed in two years probably isn't reflecting current practice.

Verifying Both

For a story to be done:

1. The acceptance criteria are verified

2. The DoD items are verified

The verification happens at PR review and merge time, not at sprint end. By the time the story is closed, both are met.

Some teams use checklists (in PR templates, in story tickets) to make verification explicit. Others rely on culture and process.

When DoD Becomes Theater

A DoD that's not actually enforced becomes theater. Patterns:

• Stories closed without all DoD items met

• DoD items that nobody checks

• DoD items that conflict with how the team actually works

The DoD is only as strong as enforcement. If items are routinely skipped, either the DoD needs adjustment or enforcement needs strengthening.

Acceptance Criteria as Conversation Starter

Acceptance criteria aren't the full spec. They're the test of completion. The conversation around the story produces the rest of the design.

Criteria that try to be complete specs balloon to dozens of bullets. Better: 3-7 criteria capturing the essence; conversation captures the rest.

A Worked Example

For a story: "User can switch between workspaces."

Acceptance criteria (story-specific):

• Workspace switcher visible to users with 2+ workspaces

• Switching to a different workspace preserves URL context where possible

• Current workspace clearly indicated

• Switcher is keyboard accessible

• Users with 1 workspace don't see the switcher

DoD (every story):

• Code reviewed

• Unit tests added

• Integration tests pass

• No accessibility regressions

• Documentation updated

• Deployed to staging

• PM accepted

For this story to be done, both lists need to be satisfied. The criteria are unique to switching workspaces; the DoD is the team's baseline.

When Acceptance Criteria Cross into DoD Territory

Sometimes a story-specific criterion is actually a DoD-applicable check. Examples:

• "No new accessibility violations" — DoD

• "Performance under 500ms" — sometimes DoD, sometimes story-specific

• "Feature flag in place" — DoD if all features go behind flags

When in doubt: if this check applies to similar stories in the future, it's probably DoD. If it's unique to this story, it's a criterion.

Acceptance Tests

Closely related: acceptance tests are the executable form of acceptance criteria. Each criterion becomes a test that passes when the criterion is met.

For automated tests, criteria + tests + DoD are three layers:

• Criteria: what should be true

• Tests: how we verify

• DoD: includes "tests are written and passing"

The cleanest version: criteria specify behavior; tests verify; DoD requires tests; both are met for done.

Anti-Patterns

Criteria duplicate DoD. "Tests are written" in every story's criteria. Move to DoD.

No DoD. Everything in criteria; inconsistent across stories.

Stale DoD. Items that no longer apply or that don't match practice.

DoD as wishlist. Items that aspirationally should happen but rarely do. Either enforce or remove.

Criteria that aren't criteria. "Story is complete." Tautological.

Key Takeaway

Definition of Done is team-wide and applies to every story. Acceptance criteria are story-specific. The DoD covers baseline quality (tests, reviews, documentation, deployment) consistently across stories. The criteria capture what the specific story should accomplish. Both must be satisfied for a story to be done. Don't duplicate DoD items in criteria; don't omit a DoD and put everything in criteria. Update the DoD as the team's practices evolve.

Related reading

• 'User Acceptance Testing (UAT): How to Run It Well'

• Designing a Test Strategy for a Growing Team

• 'Test Coverage: The Honest Version'

Keep learning. This article is part of the Software Testing Foundations path in the ShiftQuality Learning Center. Learn to design tests that catch real bugs.