Acceptance Criteria vs Definition of Done, With Examples

Acceptance criteria belong to one item: they are the conditions that show this particular story, bug or change does what was asked. The definition of done belongs to the team: it is one standard, the same for every item, that says what must be true before any work counts as finished, such as tests written, code reviewed and the change deployed. An item is done only when both are met. Acceptance criteria answer “did we build the right thing?”; the definition of done answers “did we build it properly?”.

This page is about the difference and how the two fit together. For ready-made team standards to copy, see definition of done examples; for criteria written out, see acceptance criteria examples.

Acceptance criteria: the conditions for one item

Acceptance criteria are written for a single item, before the work starts, usually by the person who asked for it or with them. Each one is a statement that is either true or false once the work is done. A different story gets a different list, because it does something different.

They come in two common shapes. A checklist of rules (“an empty basket shows the message ‘Your basket is empty’”) is quick to write and suits most items. Scenarios in the Given/When/Then form suit behaviour with several paths; the Gherkin reference↗ (opens in a new tab) describes Given as the initial context, When as the event or action, and Then as the expected outcome. Either shape works as long as a stranger could check each line without asking you what you meant.

The definition of done: one standard for everything

The Scrum Guide↗ (opens in a new tab) defines the Definition of Done as “a formal description of the state of the Increment when it meets the quality measures required for the product”. It is a commitment the whole team keeps, not a property of any one item. If an item does not meet it, the guide says, it cannot be released or even presented at the Sprint Review; it goes back to the Product Backlog. Where an organisation already has a standard, every team must follow it as a minimum, and teams working on the same product share one.

The Agile Alliance glossary↗ (opens in a new tab) draws the same line from the other side: the definition of done is a list the team agrees and keeps visible, while individual features may carry specific criteria of their own on top of it. You do not need to run Scrum to use either idea. Any team that has ever argued about whether something was “finished” already has the problem both of them solve.

Side by side

                    Acceptance criteria         Definition of done
Applies to          one item                    every item
Answers             right thing built?          built properly?
Written by          requester, with the team    the whole team, once
Written when        before the item starts      once, reviewed now and then
Changes             per item                    rarely, by agreement
Typical content     behaviour, rules, edges     tests, review, docs, deploy
Who checks          requester or reviewer       whoever moves it to done
Fails means         item does the wrong thing   item is not finished yet

One story, with both

Take a small team building an invoicing tool. Its definition of done has been agreed once and sits where everybody can read it:

- Automated tests cover the change and the whole suite passes
- Another person has reviewed the change
- It works on the staging copy, checked by someone other than the author
- User-facing text has been read by a second person
- The changelog has an entry
- It is deployed to production, or behind a switch that is off

Now a story arrives: as an accounts manager, I want to export this month’s invoices as a CSV file, so that I can load them into the accounting package. Its acceptance criteria are written for this story only:

- Export gives one row per invoice issued in the chosen month
- Columns: number, date, customer, net, VAT, gross, in that order
- Amounts use two decimal places and no currency symbol
- A month with no invoices gives a file with the header row only
- Cancelled invoices are left out
- Only people who can see invoices can export them

Three outcomes are possible, and only one of them is done.

• Criteria met, definition not met. The export works on the developer’s machine, every criterion passes, but there are no tests and nobody reviewed it. It does the right thing; it is not finished.
• Definition met, criteria not met. Tests pass, the review is signed, it is deployed, and cancelled invoices appear in the file. It is finished work that does the wrong thing, which is a bug on day one.
• Both met. The export behaves as the six criteria say, and it has gone through the same six gates as everything else. Now it is done.

Notice what the story does not say. It does not repeat “write tests” or “get it reviewed”, because the definition of done already covers every item. Copying the standard onto each card makes cards longer and, sooner or later, inconsistent.

Where people mix them up

• Writing quality gates as acceptance criteria. “Code is reviewed” on one card implies the next card might skip it. Gates that apply to everything belong in the definition of done.
• Writing behaviour into the definition of done. “Exports include a header row” is true of one feature, not of all work. It is an acceptance criterion.
• Letting a card lower the bar. A story can add to the definition of done (“also needs a data protection review”), never subtract from it. If a type of work genuinely needs a different standard, agree that openly as a team.
• Calling a single line of acceptance “the definition of done” for that card. Many tools and teams do this loosely. It works until two people mean different things by it, so keep the names apart.
• Never promoting anything. If the same criterion turns up on card after card, such as “works on a phone-sized screen”, it has become a team standard. Move it into the definition of done and stop writing it.

The definition of ready, briefly

A third list sits at the front of the process. A definition of ready is the team’s agreement about what an item must have before anyone starts it, and the Agile Alliance↗ (opens in a new tab) describes it as explicit, visible criteria a story must meet before it is accepted into the next iteration. A useful one is short: the problem is written down, acceptance criteria exist, it is small enough to finish in one go, and nothing it depends on is still undecided. The Scrum Guide itself does not use the term; it says only that items the team can finish within one Sprint are ready for selection. Treat it as a checklist for starting, never as a gate that stops urgent work.

When an AI assistant does the work

The split becomes more useful, not less, when some of the work is done by an AI agent. An agent reads the item literally and stops when it believes the item is finished. Acceptance criteria tell it what finished means for this item. The definition of done tells it what finished means for every item, and it needs to read that before it starts, not discover it at review.

• Put acceptance criteria on the item itself, in the part that says what the problem is. Giving an AI agent a task it can finish covers how to write them so an agent cannot misread them.
• Put the definition of done in the one place the agent reads at the start of every session: its rules file, or the board’s shared context. Then it applies to every item without being copied onto each.
• Ask for evidence against both lists: which criterion was checked and how, and which gates were passed. A plain “done” is a claim, not evidence.
• Keep the last gate with a person. An agent can meet every criterion and still be wrong about what the requester meant; verifying AI-generated work covers how to review without reading everything.

On fenbs the pieces map onto what a task already has. The note holds the problem and its acceptance criteria. The plan holds how the work will be done, written before the task moves to In Progress. The definition of done goes into the board’s AI context as a note, which every connected assistant reads with fenbs_get_context before touching anything. When the work is finished, the Testing section records what was checked: a status of Tested, Partly tested, Failed or Needs owner check, and notes saying what was and was not checked. A person moves it to Completed. A task an assistant finished from the pre-approved queue shows “AI done · check it” until someone presses “I’ve checked it”.

fenbs_add_context_note
  title: "Definition of done"
  body:  "A task is Completed only when: tests cover the change and
          the suite passes; a person has reviewed it; testStatus and
          testNotes say what was checked and what was not; the
          acceptance criteria in the note are each marked met."

fenbs has no sprints, story points or due dates, so there is no sprint review for the definition of done to gate. The Completed lane plays that part: the rule is simply that nothing enters it until both lists are met.