Why the Scrum Guide refuses to write yours
The Definition of Done is a commitment attached to the Increment. The moment a backlog item meets it, an Increment exists; an item that does not meet it cannot be released or even presented at the Sprint Review, and goes back to the Product Backlog. That is a hard rule, and the Guide pairs it with a conspicuous silence about what should be on the list. If the organization already has a standard, every team follows it as a minimum. If it does not, the team writes its own.
The silence is deliberate, for two reasons. The first is that done is a property of the product, not of Scrum. A Definition of Done for firmware in a medical device and one for a marketing site cannot be the same list, and a framework that named the items would be wrong for nearly everyone reading it. The second is ownership. A checklist handed down is a policy, and policies get ticked. A checklist the team wrote is a commitment, and commitments get enforced at 5pm on a Friday when somebody asks whether the documentation was actually updated.
What the rule buys is one thing: done means one thing. Everything not on the list and not finished is undone work being carried invisibly into the next sprint. That is the mechanism behind every team that has been 90% complete for a month.
Definition of Done is not acceptance criteria
This is the most common confusion in the whole vocabulary, so it is worth being blunt about.
- Acceptance criteria answer did we build the right thing. They belong to one story, are written by whoever wrote that story, and change on every ticket.
- The Definition of Done answers is it finished to our standard. It is identical for every story, is written once by the team, and changes maybe twice a year.
A story ships when it passes both. Neither one substitutes for the other.
The test for which list an item belongs on is whether you would write it on every story. “Unit tests written and passing” goes on all of them, so it is Definition of Done. “Rows with a missing Reporter surface an error instead of aborting the batch” is true of exactly one story, so it is acceptance criteria — those belong in the user story guide, next to the story they describe.
Both directions of the mistake are expensive. Copying the Definition of Done into every story produces forty copies of one list, and the day the team changes the list, thirty-nine of them are quietly wrong. Pushing story-specific items the other way — “the importer handles UTF-16” — makes the shared checklist false for every other story, and a checklist with one false line is one that people learn to skim.
The rarer failure is a team with a Definition of Done and no acceptance criteria at all. Done then means the checklist passed, and nobody has checked whether the thing does what it was built for. The checklist is a floor. It was never a specification.
A third artifact gets confused with both: the release checklist, which gates a version rather than a story. Cross-browser sweeps, regression passes and sign-off blocks belong there, not on every ticket — that is the QA release checklist, and keeping it separate is what stops a story-level list growing to thirty items.
What belongs in the team list and what belongs in the engineering one
The two bodies on this page split along a line that is easy to state: the team Definition of Done is the contract with people outside the team, and the engineering one is the contract inside it.
The team Definition of Done
Every item should be verifiable by anyone in the room, including the Product Owner and whoever stands in when they are away. Peer-reviewed, tests passing, documentation updated, deployed to staging and smoke-tested, accepted by the Product Owner, no known defects remaining. It is short enough to paste onto a story and still be read, which is the only reason it survives contact with a sprint.
The engineering Definition of Done
Coverage thresholds, integration suites, security scans, a staging gate, QA sign-off. These are checkable only by somebody with the repository open, and putting them on the shared list produces a checklist the Product Owner cannot verify and therefore stops reading. The natural home for the engineering list is the pull request template, not the ticket.
That body also carries Minimal and Enterprise variants, and the useful way to choose between them is blast radius, not company size. An internal admin tool and the payments path in the same company should not share a Definition of Done. Two tiers chosen by what breaks when it is wrong beats one tier that is too heavy for half the work and too light for the rest.
One honest note about the coverage number. Above 80% survived because it sounds right, and it is a proxy: a team can hit 90% and test nothing that matters. Keep the threshold if it is the thing stopping coverage from sliding. Delete it the moment people start writing tests for getters to clear the gate, because at that point the number is measuring compliance rather than risk.
Definition of Ready, and the honest argument against it
The Definition of Ready is the entry gate: criteria written, dependencies known, estimated, designs attached, small enough to finish inside a sprint. The case for it is real. Half-formed work entering a sprint is how sprints fail, and the case is strongest when the person writing the story sits in a different organization or timezone from the people building it.
The argument against is stronger than most agile writing admits. A Definition of Ready is a stage gate, and Scrum spent twenty years removing stage gates. In practice one group starts using it to reject another group’s work, refinement turns into a compliance exercise, and a story that is 90% ready waits a week for a field nobody will read. Readiness is a spectrum. A team that cannot start a slightly under-specified story usually has a conversation problem rather than a documentation problem, and a Definition of Ready treats the symptom.
If you keep one, keep it to two or three items, treat it as a prompt during refinement rather than a gate at the sprint boundary, and never let it block work the team is willing to start. The Scrum Guide, notably, does not mention it at all.
How a Definition of Done rots
It rots by growing. Every incident adds a line and nothing ever removes one, and somewhere around fifteen items the list stops being read: first skimmed, then ticked, then ignored. Once it is ignored, done goes back to meaning whatever each developer privately thought it meant, which is the exact state the Definition of Done existed to fix.
Two habits keep it alive, and the second is the one teams forget.
- Keep it short. If it does not fit on the story without scrolling, it is not being read. Eight or nine items is the working ceiling for a team list.
- Remove what has been automated. “No new linter warnings” belongs on the list right up until CI blocks the merge. After that it is a line asking a person to confirm something a machine already refuses to let through. Every automated line you leave on trains people to tick without checking, and that habit does not stay confined to the automated lines.
Review it on a schedule instead of on impulse — one retrospective a quarter, two questions. Which item did we tick without actually checking? Delete it, or automate it. Which incident would a new item have prevented? Add it, and take something off in the same breath.
There is a second failure mode that looks like health: a Definition of Done nobody has ever failed. If no story in six months was held back by the list, either the team is exceptional or the list describes what they already do without being asked. It is usually the second, and it costs a ritual per story to learn nothing.
When a Definition of Done is not worth writing
Two people shipping to production several times a day do not need one. The list is in your heads and in the pipeline, and writing it down documents something nobody was going to skip. Write it the week the third person joins — that is when the shared assumption stops being shared.
Research work is genuinely exempt, and the exemption should be explicit. A spike is done when the question has an evidenced answer and a recommendation, not when it has tests and a staging deploy. If your Definition of Done applies to spikes, either the list is wrong or the spike is a story in disguise.
Where the pipeline is the process — merge to main means built, tested, deployed and monitored — most of a conventional Definition of Done is already enforced by machines. The written list should shrink to the parts a machine cannot do: is it documented, and does the person who asked for it agree that it is what they asked for. A five-line Definition of Done that is true beats a fifteen-line one that is aspirational.
The last limit is the honest one for the whole artifact. A Definition of Done cannot make a team care. If items are being ticked because the sprint ends tomorrow, the problem is the schedule, and adding a line to the list makes it worse.