A “definition of done” is a specific, agreed, written checklist a team uses to decide whether a piece of work is actually complete — not just “the code compiles and does roughly what was asked,” but a concrete, shared standard covering things like tests written and passing, documentation updated, code reviewed, and deployed (or ready to deploy) to a relevant environment. The practice exists because, without an explicit shared standard, “done” quietly means something different to each person on a team, and that gap tends to surface at the worst possible time — during a release, or when a supposedly finished feature turns out to be missing tests, documentation, or handling for an edge case someone assumed was included. The formal Scrum definition is available in the Scrum Guide.
Why an implicit standard fails silently
Without a written definition, each developer's personal sense of “done” tends to reflect their own habits and priorities — a developer who values testing highly will include it by default; one who doesn't will skip it, not out of carelessness but because their personal, implicit definition of complete work never included it in the first place. Neither is being dishonest when they report a task as finished; they're applying a real, but different and unstated, standard. This is exactly the kind of ambiguity the RFC-writing guide discussed elsewhere on this shelf addresses for decisions — making an implicit assumption explicit, in writing, so it can be checked and agreed on rather than discovered as a mismatch later. When a definition of done includes reporting and approvals, read more is a useful operational reference.
The cost of this gap tends to be invisible until it isn't: a task marked done that's missing tests looks identical, in a task tracker, to a task marked done that genuinely is complete, right up until the missing tests matter — a regression slips through, or the legacy-code problem discussed elsewhere on this shelf quietly grows by one more untested piece of code.
What belongs in a good definition of done
A useful definition of done is specific enough to be checked objectively, rather than relying on individual judgment about whether a vague standard was met — “adequately tested” is hard to check consistently; “unit tests written and passing for all new logic branches, no reduction in overall coverage” is a specific, checkable claim. Common items include automated tests passing, code reviewed and approved (connecting to the code-review guide elsewhere on this shelf), relevant documentation updated (connecting to the documentation guides on this shelf), and the change actually deployed or verified in a realistic environment, not just working on the original author's machine.
- Make each item in the definition specific enough to check objectively — vague standards like “well tested” recreate the same ambiguity the definition is meant to remove.
- Apply the same definition consistently across the team — a definition that's optional or selectively enforced provides little more certainty than having no definition at all.
- Revisit the definition periodically as the team and codebase mature — a definition of done appropriate for an early-stage project's pace often needs to grow stricter as a system accumulates more users and more at stake in a regression.
- A task that doesn't meet the definition isn't done, regardless of how much of the interesting work is finished — resisting the urge to mark something complete because the hard part is over is part of what the discipline is for.
Why this connects to several other guides on this shelf
A definition of done is, in effect, a small, local RFC — a written, agreed standard that removes exactly the kind of costly-later ambiguity the RFC-writing guide discusses for larger decisions, applied here to the much more frequent, smaller-scale question of what “finished” means for any given piece of work. It also functions as a direct, practical safeguard against several of the problems discussed elsewhere on this shelf accumulating silently: undocumented code, untested logic quietly becoming legacy code, and features that technically work but were never actually verified in a realistic environment.
A definition of done is one of the cheaper process disciplines on this shelf to adopt — a short, written checklist, agreed once and applied consistently — relative to the specific, recurring class of ambiguity and rework it prevents.