Definition of Done

A Definition of Done is a single shared checklist that applies to every work item a team completes. It is the team’s standard answer to “what does done actually mean here,” and it is the same for ticket A as for ticket Z. The point is not the abstraction. The point is the list. So here is a concrete one for a team with a CI pipeline and a QA analyst:

Done means: pipeline green · tests pass and new behavior has a new test · merge request approved by at least one non-author · QA approved against the ticket’s acceptance criteria · docs updated if user-facing · ADR written if a significant decision was made · deployed · post-deploy smoke check passes and the feature verified in prod

Eight items. Each either happened or it did not. That is a real Definition of Done. A team whose honest bar is shorter, say “pipeline green, QA approved, deployed,” has a legitimate Definition of Done too. Writing it down is what stops “done” from meaning five different things to five people.

Green checkmarks are necessary, not sufficient

The trap is thinking the pipeline is the Definition of Done. It is not, because CI can only check what is mechanizable. The list splits in two, and the second half is the reason the document exists.

What the pipeline confirms on its own:

Tests pass, and the new behavior has a test that did not exist before
Lint, typecheck, and build are green
No new high-severity security findings
Coverage held its line, if you gate on it

What a human still has to confirm:

The merge request was reviewed and approved by someone who is not the author
The QA analyst actually exercised the change in staging against the ticket’s acceptance criteria, not just glanced at green tests
It is actually deployed where it needs to be, not merely mergeable
Docs or changelog updated if behavior changed
It works in prod. “The deploy succeeded” is not “the feature works.” A green deploy ships a broken feature just as happily as a working one.

Tests pass on code that does the wrong thing. They pass on code that ships without docs, or that QA never opened. Every item in the second list is a gate CI cannot stand in for, and the QA sign-off is one of them.

Conditional items need a real trigger

“Update docs if needed” gets skipped, because “if needed” has no teeth and the author is the one deciding. Conditional items only survive if the condition is itself checkable:

Docs: the trigger is “does this change user-facing behavior?” Make it a yes/no in the merge request template so the author has to answer it, not silently skip it.
ADR: not per-ticket. An architecture decision record is for a choice future-you will question, a database engine, an auth approach, an irreversible structural call. The trigger is “did we make a significant or hard-to-reverse decision?” Most tickets, no. Forcing an ADR on every ticket kills the practice by drowning the real ones.
Post-deploy: decide where your “done” line sits, merged, on staging, or live and verified, and write that down. A small team’s honest bar is usually a smoke or health check passing, a few minutes watching the error-rate dashboard with no spike, and someone clicking the actual feature in prod once.

Why writing it down has teeth

Without a written Definition of Done, “done” means whatever the person saying it had in mind. One developer’s “done” is code merged. Another’s is merged and monitored in production. The gap is invisible until something breaks, and the unfinished part, the missing test, the skipped doc, the un-run scan, accumulates as debt nobody decided to take on.

The 2020 Scrum Guide makes this formal: it names the Definition of Done as a commitment attached to the Increment. The teeth are in the consequence. If a backlog item does not meet the Definition of Done, it cannot be released or presented as complete, and it returns to the backlog. “Done” becomes binary and shared rather than a matter of individual judgment.

This is the foundation under the QA Handoff Workflows sign-off. A “QA Approved” status only means something if the developer and the analyst agreed in advance on what QA checks. Otherwise the gate is a vibe, and a ticket passes or fails on who happened to test it that day.

Done versus acceptance criteria

One distinction worth keeping straight. The Definition of Done is universal: the same quality and process bar for every item. Acceptance criteria are per-item: the conditions this feature must satisfy to behave correctly. “The export button produces a valid CSV” is acceptance criteria for one story. “All new code has tests and passes review” is Definition of Done for everything. A ticket can satisfy its acceptance criteria (the feature works) and still fail the Definition of Done (no tests, not reviewed). Both gates have to pass. See [private link] for the per-item side.

Build it like a checklist

The discipline that makes a good checklist applies directly: every item must carry a test that can fail. “Code is high quality” is not a Definition of Done item, because no observation fails it. “Passes CI and has at least one reviewer approval” is, because either it did or it did not. Items that cannot fail are decoration. Keep the list short enough that people actually run it and binary enough that running it has an answer.

Try it

Audit your last ten “done” tickets (1 hour, your tracker). Write down your team’s implicit Definition of Done as you believe it stands, five to eight binary items. Then pull the last ten tickets marked done and check each against the list. What you are looking for: the items where reality and the list disagree. Tickets closed without tests, without review, without the doc update. Each disagreement is either a gap in the list (the team does not actually hold that standard) or a gap in practice (the standard exists but is not enforced). Both are worth knowing, and you cannot see either until the implicit list is written down.

Sources

What Is the Difference Between the Definition of Done and Acceptance Criteria? — Scrum.org — DoD applies to all items, acceptance criteria to one.
The 2020 Scrum Guide — the Definition of Done as a commitment for the Increment, and what happens when an item fails it.