Definition of Done: Examples and a Checklist Template

A good definition of done is a short checklist, usually five to eight lines, that every piece of work must pass before anyone calls it finished. Each line is a check someone can actually perform: “the full test suite passes”, not “quality is high”. Below are four examples to copy, for a software team, a small web team, a content team and work done by AI assistants, then a blank template and a way to agree your own in under an hour.

If you are still sorting out how this differs from the conditions written on each card, read acceptance criteria vs definition of done first. In short: acceptance criteria change per item; the definition of done is the same for all of them.

What the good ones have in common

• Every line can be checked by someone other than the author, in minutes, with a yes or no answer.
• It is the minimum, not the ideal. The Agile Alliance glossary↗ (opens in a new tab) warns against obsessing over the list and says it should be written down and displayed, not left as an unspoken understanding.
• It covers the whole trip to the user: built, checked, reviewed, released or ready to release. Stopping at “merged” leaves the riskiest steps out.
• It is agreed by the people who have to meet it. A definition handed down from outside gets met on paper.
• It changes rarely, and only by agreement, so “done” means the same thing in March as in May.

Example 1: a software team

For a product team shipping an application with automated tests and a staging environment. The changelog line follows the common Keep a Changelog↗ (opens in a new tab) habit of recording changes under an Unreleased heading until the next release.

- The acceptance criteria on the item are each met
- New or changed behaviour is covered by automated tests
- The full test suite and the linter pass in CI
- Another developer has reviewed and approved the change
- It has been checked on staging by someone other than the author
- No new errors appear in the error tracker after deploying to staging
- The changelog has an entry under Unreleased
- It is deployed to production, or merged behind a switch that is off

Example 2: a small web team

For two or three people building marketing sites or small web apps, where there may be no dedicated tester. Accessibility is a line of its own because it is the check most often skipped under pressure; the UK government’s service manual↗ (opens in a new tab) sets level AA of WCAG 2.2 as the minimum for public services, which is a sensible bar for anyone.

- Works in the latest Chrome, Safari and Firefox
- Works at phone width (390px) and desktop width without sideways scrolling
- Keyboard-only use reaches every link, button and form field
- Images have alt text; colour contrast passes an automated check
- Page title and meta description are set; no broken links
- Forms have been submitted once for real and the result arrived
- The client or requester has seen it on the staging address
- Live, and checked once on the live address after release

Example 3: a content team

For articles, help pages, newsletters and similar. Content teams often have no definition of done at all, which is why the same correction gets made by the same editor every week.

- The brief’s question is answered in the first paragraph
- Every fact, figure and quotation has a source that has been opened
- Every link has been clicked and loads
- A second person has edited it, not only proofread it
- House style applied: spelling, headings, dates, numbers
- Title and summary written for the place it will appear
- Images have alt text and permission to use them is recorded
- Published or scheduled, and the live version checked once

Example 4: work done by AI assistants

When an AI agent does the work, the definition of done has to carry more of the load, because the agent will stop at the point where it believes the job is finished. Three things matter most: evidence attached to the work, checks that were actually run, and a person who reviewed the result. Anthropic’s Claude Code best practices↗ (opens in a new tab) put the evidence point directly: have the agent show evidence, such as the test output, the command it ran and what it returned, or a screenshot, rather than assert success.

- The item's acceptance criteria are each marked met, with how
- Evidence is attached: commit, test command and its result line,
  or a screenshot taken after the change
- Checks were run, not assumed; anything not checked is listed
- No tests were deleted, skipped or weakened to make them pass
- The change stays inside the area the item named
- Anything noticed but not fixed is filed as a new item
- A person has reviewed the result before it counts as done

The last line is the one that makes the rest honest. An agent can be told to meet every other line, and usually will; only a person can confirm it did what was meant rather than what was written. How much of that review to do, and when sampling is enough, is covered in verifying AI-generated work.

Shorter ones for other kinds of work

• A data report: the numbers reconcile with the source totals; the query or spreadsheet is saved with it; a second person has checked three figures by hand.
• An infrastructure change: it was applied to a test environment first; there is a written way back; monitoring shows no new alerts an hour after the change.
• A design: it has been checked at phone and desktop sizes; the developer who will build it has seen it; open questions are listed rather than guessed.
• A support macro or canned reply: it has been sent to a colleague as a test; every link works; it has an owner who will update it.

A checklist template to copy

Fill in each line with your own check. Delete any line that does not apply rather than keeping it “for later”; a line nobody checks teaches everyone that the list is optional.

Definition of done: <team or kind of work>
Agreed: <date>   Next review: <date>

Built
  - The item's acceptance criteria are each met
  - <the automated check that must pass>

Checked
  - <who checks, other than the author, and where>
  - <the manual check most often forgotten>

Reviewed
  - <who reviews, and what they look at>

Released
  - <what "released" means: live, scheduled, behind a switch>
  - <the one check after release>

Recorded
  - <where the evidence goes: the item, a changelog, a log>

How to agree one in under an hour

1. Ask everyone who does the work to list, on their own, the last three things that came back after being called finished, and why.
2. Group the reasons. Each group that is a missing check (“nobody tried it on a phone”) is a candidate line.
3. Write each candidate as a check someone can perform, with a yes or no answer. Drop anything that stays vague.
4. Keep the lines you would genuinely stop a release for. Aim for five to eight; more than ten means some are wishes.
5. Put it where the work is: on the board, in the repository, in the assistant’s rules file. The Scrum Guide↗ (opens in a new tab) makes one more point worth keeping even outside Scrum: where the organisation already has a standard, it is the minimum, and teams on the same product share one definition.
6. Set a date to look at it again, a month out.

Keeping it short and alive

• Promote what repeats. If the same line keeps appearing in acceptance criteria, it belongs in the definition of done.
• Remove what nobody checks. If a line has not caught anything in months and nobody actually performs it, delete it or make it real.
• Add after a failure, deliberately. When something slips through, ask which line would have caught it. If none, consider adding one; if one should have, ask why it did not.
• Keep one per kind of work, not one per person. A content item and a code change can have different lists; two developers should not.

Keeping a definition of done on a fenbs board

fenbs does not have sprints, story points or due dates, so the definition of done guards the Completed lane rather than a sprint review. Write it as a note in the board’s AI context: anyone who can see the board can read it, and every connected AI assistant reads it with fenbs_get_context before it starts work. Acceptance criteria go in each task’s note, and the plan says how the work will be done.

When the work is finished, the task’s Testing section records the evidence: a status of Tested, Partly tested, Failed or Needs owner check, and notes saying what was checked, where, the result and what was not. The board can filter by it, and “Completed, not tested” is the list to read before every deploy. Moving between lanes is its own permission, so a team can keep the move to Completed with people. A task an assistant finished from the pre-approved queue shows “AI done · check it” until somebody presses “I’ve checked it”.