Definition of done: examples and a checklist

Published 19 October 2026

A definition of done (DoD) is the list of conditions every piece of work must meet before a team calls it done — the same list for every story: reviewed, tested, documented, released where it should be. Acceptance criteria say what one story must do; the definition of done is the quality bar for all of them. Below are examples for different kinds of teams, a checklist to copy, and how the definition of done differs from acceptance criteria and a definition of ready.

Definitions of Done are not specific to individual items of work. They are global rules, to set expectations and norms both within the team and with stakeholders.

— r/agile, December 2024

What is the definition of done?

The Scrum Guide defines it as “a formal description of the state of the Increment when it meets the quality measures required for the product.” It is a hard line: “If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.”

The idea is used outside Scrum too: one shared answer to “is it done?”, so that “done” means the same thing to the developer, the tester, the product owner and whoever reports progress.

Definition of done examples

A product team that ships continuously:

- Code reviewed by at least one other
  developer
- Acceptance criteria met, checked by the
  product owner
- Automated tests written and passing in
  CI
- No new critical or high-severity defects
- Released to production behind a feature
  flag
- Monitoring and alerts in place for the
  change
- User-facing help updated

An agency team building for a client:

- Code reviewed; automated tests passing
- Acceptance criteria met, demonstrated on
  staging
- Tested on the browsers and devices in
  the contract
- Built against the signed-off version of
  the requirements, or an approved change
  request
- Client documentation updated
- Ready for the client's acceptance
  testing

A team that uses AI coding agents:

- The developer who commits can explain
  every change
- Tests check the acceptance criteria, and
  a person read them — not only the agent
  that wrote the code
- Code reviewed by someone other than the
  author
- The spec the agent built from is updated
  to match what was built
- No new critical defects; CI passing

How strict to be varies. One commenter’s whole definition: “Done: the code is in use in production” (r/agile, 2023). What does not vary is testing: “You can’t call something done if it’s not been tested” (r/agile).

Definition of done checklist template

Copy it into Confluence, your team’s wiki or Jira. Keep it to what you will actually check.

DEFINITION OF DONE

Team:      [team name]
Version:   [n], agreed [date]
Applies:   every story and bug, before it
           counts as done

CODE
[ ] Reviewed by [who]
[ ] Meets the coding standards in [link]

TESTS
[ ] Acceptance criteria met and checked by
    [role]
[ ] Automated tests written and passing in
    CI
[ ] [Regression, accessibility,
    performance checks]

QUALITY
[ ] No open defects of severity [x] or
    higher
[ ] Security and privacy rules in [link]
    followed

RELEASE
[ ] Deployed to [environment]
[ ] [Feature flag / release notes /
    monitoring]

DOCUMENTATION
[ ] [User help / API docs / runbook]
    updated
[ ] Requirements or spec updated if
    behaviour changed

Changes to this list are agreed by the
whole team at a retrospective.

The kitchen version, from one commenter, shows the idea: “dishes cleaned and put away, counters free of debris and residue, and empty trash can with a fresh liner. I didn’t specify the HOW” (r/agile). The definition of done says what state the work must be in, not how to get there.

Definition of done vs acceptance criteria vs definition of ready

Acceptance criteria are per item; the definition of done is a set of “rules to observe applicable to all items” (r/agile). A story is finished when both are met. More on the first in the acceptance criteria template, and on the story itself in the user story template.

A definition of ready is the mirror image: what a backlog item needs before the team starts it — for example a clear story, acceptance criteria, a size and linked designs. The Scrum Guide does not mention it; it is a practice some teams add.

Who creates the definition of done?

The Scrum Guide answers it: “If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.” Several teams on one product share one. One way to start: the developers draft it, the product owner and testers add what they need, and the team revisits it at retrospectives.

Definition of done for AI-assisted development

When an agent writes much of the code, “reviewed” and “tested” can be ticked without anyone understanding the change. One commenter, in an r/agile thread on the question:

Developers read through AI output, it looks reasonable, they commit. Three weeks later something breaks and they realize they never actually understood the branching logic in a helper function they “reviewed.”

— r/agile, April 2026

The thread’s original question was whether “developer understands the code” should be “an explicit requirement now”. Another commenter, in a later thread, would keep two things apart: “I’d separate “Done” from permission to merge or release. A change can pass its quality checks and still need approval before it goes live” (r/agile, October 2026).

The third example above adds what changes with an agent: the person who commits can explain it, the tests were read by a person, and the spec the agent worked from is brought up to date — or the next agent builds from a spec that no longer matches the code. That is spec drift.

Common mistakes

• “Done” before testing. Development is done, QA is next sprint. That is not done.
• A checklist nobody reads. “It should be concise. I’ve seen massive checklist being called DoD and teams struggled comprehending them, causing more drama than it solves” (r/agile).
• A definition of done per story. What one story must do is its acceptance criteria.
• Items nobody can check. “High quality” is not a condition; “no open defects above medium” is.
• Written once and forgotten. Revisit it when the team, the product or the tools change.

Where Specroot fits

This is the problem Specroot works on: work that is done against a named version of the requirements, so that “done” still means something when the requirements change. Specroot for agencies and consultancies.