Definition of done

The definition of done is one team-wide checklist every story clears before it ships. A sample DoD, who owns it, and how it differs from acceptance criteria.

The definition of done is one checklist for the whole team — the standard every story clears before it counts as complete. Acceptance criteria are per story; the definition of done is global. Confusing the two is how “done” quietly comes to mean “works on my machine.”

Every team has felt the gap between “the developer says it’s done” and “it’s actually shippable.” The definition of done closes it. You agree it once and enforce it every sprint, regardless of what any individual story does. Without it, “done” is a per-person opinion — and the difference surfaces in the demo, or worse, in production.

A definition-of-done checklist (example)

A workable starting point for a team shipping to a web app:

  • Acceptance criteria met and verified.
  • Code reviewed and merged to the main branch.
  • Automated tests written and passing; no new flaky tests.
  • No known regressions or open critical bugs against the story.
  • Documentation and changelog updated where the change is user-facing.
  • Deployed to staging and smoke-tested.
  • Product owner has accepted it.

Steal this, then cut it to what your team will actually enforce. A definition of done with a line nobody checks is worse than a short one — it trains the team to treat the whole list as decorative. Keep it on one screen, and keep every item falsifiable.

Definition of done vs acceptance criteria

This is the distinction teams trip over most. The acceptance criteria for a login story are specific to login — correct credentials land you on the dashboard, three wrong attempts lock the account. The definition of done — reviewed, tested, deployed — is identical for the login story, the search story, and the billing story. Criteria are local and answer “did we build the right thing?” The definition of done is global and answers “is any of our work ever shippable?” A story isn’t finished until it passes both gates.

Definition of ready vs definition of done

They’re bookends, not symmetric twins. The definition of ready gates a story into the sprint — small enough, clear enough, estimated. The definition of done gates the finished work out. Ready is about the story; done is about the work. Teams that only have one usually have ready (because unready stories are loud) and quietly let “done” drift — which is how carry-over and “90% complete” stories accumulate.

The three checklists stop blurring together once you see what each one gates:

Definition of readyAcceptance criteriaDefinition of done
ScopeGlobal — every storyLocal — this storyGlobal — every story
GatesEntry into the sprintThe story’s own outcomeExit from the sprint
Answers”Can we start this?""Did we build the right thing?""Is it shippable?”
Owned byTeam, with the product ownerProduct owner, with the teamThe team

Who owns the definition of done

The team writes it; the team enforces it. The scrum master facilitates, and the product owner weighs in on the acceptance bar, but the engineers decide what “done” technically requires — because a loosely defined “done” is a debt they pay, not management. Revisit it in a retrospective when the same gap keeps slipping through; that’s the signal a line is missing.

What goes wrong

The definition of done becomes a poster. It’s pinned to the team wiki, recited in onboarding, and ignored under deadline pressure — “we’ll write the tests next sprint.” Two sprints later the test debt is structural and the definition is a fiction. When “done” is soft, velocity inflates: the team books points for work that isn’t really shippable, and the forecast quietly stops meaning anything.

The fix isn’t a longer list; it’s a shorter one the team will hold the line on. A definition of done is only as real as the story you’re willing to not mark done because it failed one.

Acceptance criteria gate the story. The definition of done gates the team. Keep it short enough that you’ll actually enforce it — an unenforced gate is just paperwork.

Frequently asked questions

What is the definition of done in agile?

The definition of done is a single checklist every story must satisfy before it counts as complete — typically tested, code-reviewed, merged, documented, and deployed to staging. It is one shared standard for the whole team, not a per-story list, and it exists so that “done” means the same thing every time someone says it.

What is the difference between the definition of done and acceptance criteria?

The definition of done is global — the same gate for every story. Acceptance criteria are local — specific to one story. Acceptance criteria say what this feature must do; the definition of done says what “shippable” means for any work the team produces. A story needs to pass both.

What is a definition of done checklist?

A short, explicit list of conditions applied to every story: code reviewed and merged, tests written and passing, no known regressions, docs updated, deployed to a test environment, and product-owner accepted. The exact items vary by team, but it should fit on one screen and every line should be checkable.

What is the difference between the definition of ready and the definition of done?

The definition of ready gates entry into the sprint — the bar a story clears before the team commits to it. The definition of done gates exit — the bar the finished work clears before it ships. Ready is about the story being well-formed; done is about the work being releasable.

Who creates the definition of done?

The development team owns it, usually with the scrum master facilitating. The product owner has input on the acceptance bar, but the people doing the work decide what “done” technically requires — because they are the ones who pay when it is defined loosely.