Definition of Done
A shared, written checklist that defines what 'done' means for a unit of work — the single most important quality discipline in agile delivery.
Definition
The Definition of Done (DoD) is the explicit, agreed-upon checklist that every product backlog item must meet before it can be considered complete. It typically covers code, tests, documentation, deployment, and acceptance criteria, and it applies uniformly across the team. Scrum codified the concept, but every flavour of agile — Kanban, XP, SAFe — depends on a strong DoD to keep "done" from quietly meaning "kind of working in dev".
Why It Matters
A team I coached at a fintech had a velocity of 42 story points per sprint and a customer satisfaction score in the low 30s. Their DoD was "merged to main". Items shipped, broke in production, and got reopened — none of which the burndown showed. We rewrote DoD to include automated tests passing, code review, security scan clean, deployed to staging, product owner acceptance, and documentation updated. Velocity dropped to 28 points for two sprints. CSAT climbed to 71 within a quarter. Real done is slower than fake done, and worth every minute.
A Concrete Example
- All acceptance criteria pass in staging.
- Unit-test coverage ≥ 80% on changed files.
- Integration tests green.
- Code reviewed by at least one peer, no open comments.
- Security scan clean (no high or critical findings).
- Accessibility checks pass for any UI changes.
- Deployed to staging and verified by QA.
- Documentation (API docs, runbook, user-facing if relevant) updated.
- Product owner has signed off.
- Feature flag (if used) configured and tested.
Length is not the point; rigour is. A 5-item DoD that the team genuinely meets every time beats a 25-item DoD that gets waived.
Practical Lessons Learned
- DoD is owned by the team, not imposed. Imposed DoDs get gamed.
- Acceptance criteria are not DoD. Acceptance criteria are story-specific; DoD applies to every story.
- Revisit it every quarter. Teams add maturity, infrastructure changes, security requirements evolve.
- Show DoD on the board. Print it; pin it next to the To Do column.
- The PO doesn't unilaterally weaken DoD. Pressure to ship is real, but skipped DoD always returns as production incidents or rework.
Common Mistakes
- DoD = "merged to main". Merging is a step, not a definition of done.
- Different DoD per developer. Defeats the entire point.
- Never updated. A 3-year-old DoD is usually obsolete in three places.
- Aspirational DoD. "All performance tests pass" when the team has no performance tests is theatre.
- Conflating DoD with release criteria. DoD is the team's; release criteria belong to the release manager and may be stricter.
- Letting velocity drive DoD compression. "We need more points this sprint" is the start of every quality collapse I've ever seen.
Expert Tips
- Tie DoD violations to the retrospective. Items that shipped without meeting DoD are a retro topic, not a blame topic.
- Automate as much as possible. CI pipelines that block merges on coverage and security scans make DoD enforce itself.
- Differentiate DoD for spikes, defects, and stories. A spike's DoD is "documented findings"; a story's is full.
- Use a SAFe-style "Definition of Ready" to keep junk out of sprints in the first place; DoR and DoD are bookends.
- Coach junior team members on DoD reasoning. They are usually the ones who feel pressured to cut corners.
Key Takeaways
- Definition of Done is the team's shared standard for completeness; it applies uniformly to every story.
- Apparent velocity rises when DoD is loose; real velocity rises only when DoD is enforced.
- DoD belongs to the team and should evolve quarterly as practices mature.
- Automation in CI pipelines is the most reliable enforcer.
- Conflating DoD with acceptance criteria or release criteria muddies all three.
Related Encyclopedia Entries
Related Research Articles, Case Studies & Tools
Frequently Asked Questions
Is DoD the same as acceptance criteria?
No. Acceptance criteria are specific to a single story (what success looks like for that feature). DoD applies to every story uniformly (tests pass, code reviewed, deployed, etc.).Who writes the DoD?
The whole team — developers, QA, product owner — together. Imposed-from-above DoDs are routinely ignored.How long should it be?
Long enough to be honest; short enough to be remembered. 8–12 items is typical for mature teams.Can DoD change?
Yes, and it should. Revisit it quarterly. Add items as the team matures, remove items that automation has subsumed.What about DoD for spikes and bugs?
Different DoDs are fine, provided they're written down. A spike's DoD is usually 'findings documented and shared'. A bug's includes 'regression test added'.How do we enforce it?
Automation in CI is the strongest enforcer. Peer review and a visible DoD on the board cover the rest. Retrospectives catch what slips.Doesn't a strict DoD slow the team down?
Apparent velocity slows; real throughput rises because rework collapses. Within two to three sprints the trade is unambiguously positive.What is a common misconception about Definition of Done?
That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.Which related encyclopedia entries should I read alongside Definition of Done?
Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.How does Dr. Hassan Eliwa's research treat Definition of Done?
Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Definition of Done is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.How is Definition of Done defined on PMMilestone Research & Insights?
A shared, written checklist that defines what 'done' means for a unit of work — the single most important quality discipline in agile delivery. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.
People also ask
Follow-up questions practitioners search for next — each one points to the calculator, template or reference entry that answers it.
Which learning track covers this end-to-end?
Structured tracks from beginner planner to programme controls director. Project Controls Academy ↗
Which book goes deeper than this entry?
Practitioner field handbooks with worked numerical examples. Books & Publications ↗
Which calculator on PMMilestone.org applies here?
The integrated EVM workbook covers most cost-schedule diagnostics. EVM Calculator ↗
Where is this in the glossary?
Quick-lookup definitions across 1,200+ PM terms. PM Glossary on PMMilestone.org ↗
Related Entries
Further reading on PMMilestone.org
Curated companion resources hosted on the flagship platform, PMMilestone.org.
- For practitioners who want to go deeper, the Project Controls Academy.
- Engineers researching this topic typically continue with the Learning Tracks.
- A practical companion to this entry is the Books & Publications.
- Closely related on the flagship platform is the EVM Calculator.
- Useful alongside this article is the Schedule Health Checker.
- Many readers follow this up with the PMMilestone.org knowledge hub.