What a definition of done is for
The definition of done exists so that done means the same thing on Monday as it did on Friday, for every story and for every person on the team. Without one, done means whatever the last person to touch the story thought it meant, and the undone work (the tests not written, the review not held, the migration not run) accumulates as invisible debt that appears at release time. The Scrum Guide makes the DoD a formal commitment for the increment; Lisa Crispin and Janet Gregory treat it as the place where the whole team's quality practices are written down. Both views agree on one thing: it is a checklist, and it is binary. An item is met or it is not. This is also where the tester stops being a gatekeeper, as described in the tester's role in agile teams: the checklist decides, not a person.
The story layer
Story-level items are the ones that can and should be true for every story before it moves to done on the board. Keep them to about eight. The testing items are spelled out rather than summarized as tested, because tested is exactly the word that hides undone work.
| Item | Evidence | Who confirms |
|---|---|---|
| Code reviewed by at least one other developer | approved review on the change | reviewer |
| Unit tests written for new logic; suite green | pipeline run on the merged change | pipeline |
| Acceptance examples automated and passing | acceptance suite run against the story build | developer and tester |
| Exploratory session run and notes filed | session sheet linked from the story | tester |
| No open defects of severity 1 or 2 on the story | defect tracker query | team |
| Static analysis and security scan clean for touched code | pipeline stage | pipeline |
| Documentation and configuration updated where behavior changed | linked change | developer |
| Product owner has seen the working story | comment or demo note on the story | product owner |
The sprint layer
Sprint-level items apply to the increment as a whole at the end of the sprint. They are the checks that are wasteful to run per story but essential per sprint.
| Item | Evidence | Why it sits at sprint level |
|---|---|---|
| Full regression suite green on the integrated build | pipeline run on the sprint build | too slow per story; essential before the increment is offered |
| No open severity 1 or 2 defects anywhere in the increment | defect tracker query | a story can be done while another story broke it |
| Flaky checks below 1 percent of runs, or quarantined with an owner | pipeline flakiness report | a suite nobody trusts is not a regression suite |
| Integration with dependent teams' builds verified | integrated environment run | cross-team breakage appears only when everything runs together |
| Sprint review held and the increment accepted by the product owner | review notes | the customer view of done |
| Test environment and test data reset to a known state | environment log | the next sprint starts clean |
The release layer
Release-level items are the ones that make sense only for the whole product going to real users. Several of them are the province of the test strategy rather than the sprint.
| Item | Evidence | Typical threshold |
|---|---|---|
| Performance test on a production-like environment within budget | performance report | p95 response within target at expected peak load |
| Security testing completed for the release scope | scan and test report | no open high or critical findings |
| Accessibility checks passed for changed screens | audit checklist | agreed conformance level |
| Rollback rehearsed on staging | rehearsal log | rollback completes within the agreed window |
| Monitoring and alerts in place for new features | dashboard and alert configuration | each new endpoint has a health signal |
| Release notes and support documentation published | published artifacts | support team briefed |
Definition of done versus acceptance criteria
| Aspect | Definition of done | Acceptance criteria |
|---|---|---|
| Scope | every story, sprint and release | one story |
| Who writes it | the team, in a workshop, revised at retrospectives | product owner with the three amigos, per story |
| What it answers | is the work finished to our standard | does this story do what was asked |
| Changes | rarely; every few sprints | every story is different |
| Typical item | exploratory session run and notes filed | a member with a coupon at 250.00 gets 50.00 off |
| Failure if missing | hidden undone work, release surprises | the wrong feature built correctly |
How to write one in a 90 minute workshop
- Gather the whole team (10 minutes). Developers, testers, product owner, and whoever runs operations for you. Explain the purpose: a checklist we will actually enforce, not a statement of values.
- List what done currently means (15 minutes). Everyone writes, silently, the things they check before calling a story done. Cluster the notes. The gaps between people's lists are the reason you are in the room.
- Sort into layers (15 minutes). Story, sprint or release. If an item is expensive per story, push it up a layer rather than dropping it.
- Make every item checkable (25 minutes). For each item, name the evidence and who confirms it. Rewrite any item that cannot produce evidence. Tested becomes unit tests green, acceptance examples pass, exploratory session filed.
- Cut to what you will enforce today (15 minutes). Items the team cannot meet this sprint go on a separate list labeled aspirations, with a date. The DoD contains only what is enforced now. Aim for under 25 items in total.
- Agree the audit (10 minutes). Who samples closed stories, how many, how often, and where the compliance number is published.
How to audit compliance
Each sprint, someone who did not work on the stories (rotating, or the test lead) samples 10 closed stories and checks each DoD item for evidence. Score the sprint as the percentage of item-checks that had evidence. Publish the number next to velocity. Below 90 percent, discuss at the retrospective: was the item unrealistic, was the evidence hard to produce, or was the team under pressure and skipping it? Each answer has a different fix. Track the number over time; a DoD that is met 95 percent of the time for three months is ready for a new item from the aspirations list. Pair the audit with escaped defect counts: when a class of production defect keeps appearing, the DoD is missing an item that would have caught it. That loop, from escaped defect to new checklist item to measured compliance, is the mechanism that makes continuous testing actually continuous.
Pick a story that closed last week. Can you produce evidence for every DoD item in five minutes? If not, the DoD is aspirational, and the team should either shorten it to what it does or start doing what it says.
Common mistakes
- The aspirational DoD. Forty items copied from a book, of which twelve are practiced. Everyone knows which twelve, so the document has no authority. Shorten it to the twelve and add items only as they are actually adopted.
- The unenforced DoD. Written once, framed on a wall, never audited. Without a sampled compliance number it decays within two sprints.
- DoD as acceptance criteria. Story-specific items (the report exports to CSV) in the DoD, or DoD items (code reviewed) repeated in every story's acceptance criteria. Keep the generic and the specific apart.
- Changing it mid-sprint. The DoD is a commitment for the sprint. Change it at the retrospective, and apply changes from the next sprint.
- Vague items. Tested, documented, secure. Each hides the work it names. Replace with the evidence-producing version.
- Dropping the sprint and release layers. A story-only DoD leaves the regression suite, performance and rollback to chance. They are where release-day surprises come from.
Common questions
What is the difference between definition of done and acceptance criteria?
The definition of done is one checklist that applies to every story, sprint and release, written by the team. Acceptance criteria describe what one particular story must do, written per story with the product owner. A story is complete when both are satisfied.
How many items should a definition of done have?
Five to ten per layer and under 25 in total. More than that and the team stops reading it. If you have more candidates, keep the rest on an aspirations list and promote them one at a time as they become routine.
Who owns the definition of done?
The development team, including its testers, with the product owner's agreement on the items that affect the customer. In organizations with several teams, the program may set minimum items that every team's DoD must include; teams add their own on top.
Can a story be done if the exploratory session found bugs?
Yes, if the bugs are fixed or are below the severity threshold the DoD names and have been logged with the product owner's agreement. Done does not mean defect-free; it means the agreed checks were run and the agreed thresholds are met.
How often should we revise the definition of done?
Review it at every third or fourth retrospective, and whenever a class of escaped defect shows the checklist missed something. Apply changes from the start of the next sprint, never in the middle of one.
What do we do with stories that do not meet the DoD at sprint end?
They are not done. They return to the backlog, are re-estimated for the remaining work, and are not counted in the sprint's delivered work. Partial credit is how undone work becomes invisible.
Sources
- The Scrum Guide, Schwaber and Sutherland
- Principles behind the Agile Manifesto
- Lisa Crispin and Janet Gregory, Agile Testing and More Agile Testing
Further reading named in the text
- Mike Cohn, Succeeding with Agile: Software Development Using Scrum (Addison-Wesley, 2009)
- Gojko Adzic and David Evans, Fifty Quick Ideas to Improve Your User Stories (Neuri, 2014)
This guide is part of the agile testing hub. It is best read alongside acceptance test driven development and agile program management, which cover the neighbouring questions.