What is the Definition of Done?
The Definition of Done is the team-wide checklist stating when work truly counts as finished—no silent waivers allowed.
DEFINITION
The Definition of Done (DoD) is one of the strongest quality contracts in Scrum (and broader agile teamwork). It states explicitly what “finished” entails so the meaning cannot drift member by member. Without a crisp DoD, pseudo-shippable slices crowd increments—perhaps coded yet review-free, documented yet untested—until release risk explodes. A healthy DoD encodes communal engineering discipline: peer review done, automated suites green in CI, observable deployment to a staging slice, ancillary docs maintained—you tailor the bullets as a squad. Everyone knows the clauses, honours them without hero exceptions and evolves the list thoughtfully after retrospectives mature the culture. As quality expectations rise—security scans, telemetry hooks—fold them in rather than leaving them tacit folklore.
CONNECTIONS
Leadership
Managers enable clarity—competing notions of completeness breed conflict. Transparent done gates are part of reinforcing feedback rhythms.
Artificial intelligence
AI-delivered artefacts deserve their own done rules: mandatory human appraisal for risky hallucination surfaces, versioning of prompts/models, reproducibility artefacts—whatever signals “safe enough to ship”.
Project management
Translating backlog items without shared exit criteria bankrupts RAID logs late; DoD aligns risk tracking with factual completion evidence.
KEY POINTS
- Binding on the entire Scrum Team—no rogue micro-definitions mid-sprint unless everyone agrees.
- Prevents synonym drift where “done” quietly means eighty percent readiness.
- Retrospectives are the natural venue to refine DoD—not hallway deals.
- Without shared criteria, undone work leaks into production debt.
- Binary honour: satisfies every checkbox or backlog item returns—not “mostly shipped”.
EXAMPLE
A product trio workshops DoD anchors: reviewed code, green unit suite, UX copy present, staging deployment validated. Retro adds “no Sev-1 CVEs per scanner”—the bar rises as maturity allows. Subsequent sprints bleed less rework because expectations stay explicit.
MISCONCEPTIONS
Aren’t acceptance criteria identical to DoD?
No. Acceptance criteria sit on a particular user story—they describe stakeholder satisfaction signals. DoD crosses every backlog item uniformly.
Can we customise DoD per story?
That collapses portability—exceptions belong in supplementary acceptance bullets, not redefining the global contract each time.