Definition of Done

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

• Agile Project Management
• Sprint Retrospective
• Backlog Refinement
• Velocity
• Quality Management
• Kanban

Related Research Articles, Case Studies & Tools

• Project Controls Academy
• Learning Tracks
• Agile DoD Template
• PM Glossary
• Fintech DoD-rewrite case study
• Quality vs velocity research notes