Definition of done (DoD): checklist and examples
The definition of done (DoD) is one checklist every story clears before it ships. Example checklists, how to write yours, and DoD vs acceptance criteria.
The definition of done (DoD) is the short checklist a team agrees every story must meet before it counts as complete: reviewed, tested, merged, deployed, accepted. It is one standard for the whole team. 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.
What the definition of done means in Scrum
The Scrum Guide calls it “a formal description of the state of the Increment when it meets the quality measures required for the product.” In plain terms, the definition of done is the commitment attached to the Increment, one of the three Scrum artifacts. Work that meets it becomes part of the Increment. Work that doesn’t can’t be released or shown at the sprint review; it goes back to the product backlog.
If your organization already sets a definition of done, every team uses it as the minimum and can add to it. If it doesn’t, the team writes its own. The idea isn’t limited to Scrum: Kanban teams often write the same list as the policy for moving work into their final column.
Definition of done examples
Definition of done checklist example: a software team
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 example: a team that doesn’t ship code
The same idea works for a marketing, content, or design team. A content team’s definition of done might read:
- The brief’s acceptance criteria are met.
- Edited by someone other than the author.
- Facts, figures, and links checked.
- Accessibility basics done: alt text, heading order, readable contrast.
- Approved by whoever requested it.
- Published or handed off, and recorded where the team can see it.
Story, sprint, and release levels
Scrum asks for one definition of done for the Increment. In practice, many teams group the checks by where they naturally happen:
| Level | Applies to | Typical items |
|---|---|---|
| Story | Every backlog item | Code reviewed, tests passing, acceptance criteria met, product owner accepted |
| Sprint | The Increment as a whole | Integrated on the main branch, regression suite green, deployed to staging |
| Release | What reaches customers | Release notes written, security and performance checks run, support briefed |
Keep the story level as the core list. If a check can only happen at release, write that on the list too, so nobody marks a story done while assuming someone else will catch the gap later.
How to write a definition of done
- Start from what keeps escaping. Look at the last few sprints: the bugs found after “done”, the stories that bounced back, the carry-over. Each one points at a missing line.
- Write it with the whole team. The people doing the work agree it in one session, with the scrum master facilitating and the product owner in the room. A list handed down from outside is one the team won’t defend under deadline pressure.
- Make every line checkable. “Tested” is a mood; “automated tests written and passing in CI” is a check. If two people could disagree about whether a line is met, rewrite it.
- Cut it to what you’ll enforce now. We’d start with five to eight lines. Add the aspirational ones when the team can actually meet them.
- Put it where the work happens. A checklist in the ticket template or on the board’s “done” column gets used. A page on the wiki gets forgotten.
- Review it in the retrospective. When the same gap slips through twice, add a line. When a line gets ticked without anyone checking it, ask whether it still earns its place.
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 ready | Acceptance criteria | Definition of done | |
|---|---|---|---|
| Scope | Global, every story | Local, this story | Global, every story |
| Gates | Entry into the sprint | The story’s own outcome | Exit from the sprint |
| Answers | ”Can we start this?" | "Did we build the right thing?" | "Is it shippable?” |
| Owned by | Team, with the product owner | Product owner, with the team | The 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.
How the definition of done changes your estimates
Story points size the work all the way to done, not to “code complete.” So the definition of done is baked into every estimate. Add a line like “performance tested” and every story gets a little bigger. When the list changes, re-check your reference stories in the next planning session, or velocity will dip for a reason nobody can name.
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 (DoD) 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.
How do you write a definition of done?
Start from what keeps escaping: the bugs, rework, and carry-over from the last few sprints. Agree the list as a whole team, write each line so it has a yes-or-no answer, cut it to what you will actually enforce, and put it where the work happens, such as the ticket template. Then revisit it in the retrospective whenever something slips through.
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.
Related reading
- Agile estimation: the complete guide: the hub for everything here.
- Acceptance criteria: the per-story test the definition of done is often confused with.
- Definition of ready: the entry gate at the other end of the sprint.
- Planning poker mistakes: how a soft “done” inflates velocity.