Skip to content

Definition of Done

Completion standard — instantiates Sufficiency-Bounded Work Containment

A single reusable, team-agreed standard for what "done" means — the same bar every work item must clear — reviewed and re-tightened as the team learns.

A Definition of Done is one reusable, team-agreed standard for what "done" means — the same bar every item must clear, defined once and applied to all of them. Its defining move is that the finish line is independent of the resource container and independent of the individual item: done is settled by the standard, not by how much time or budget is left, and not by how any one person feels about their own work. That independence is what stops work from expanding to fill the slot — there is a fixed line to reach and then stop at. And because "good enough" shifts as a team learns, the standard is not carved in stone: it is revisited on a loop and tightened or trimmed so it neither ossifies nor quietly ratchets upward into gold-plating. Where an Acceptance Criteria Checklist is unique to one item, the Definition of Done is the shop-wide bar behind all of them.

Example

A software team used to call a story "done" whenever its author felt it was — so some shipped without tests and others were polished far past need. They agree one Definition of Done that applies to every story: peer-reviewed, unit tests passing, user-facing docs updated, deployed to staging, no known critical bugs. Now "done" is the same short bar for a one-line fix and a major feature, independent of how much sprint time remains — and when a developer keeps refactoring a module that already meets it, the standard is the answer: it's done, stop. Two months on, a run of staging incidents exposes a gap; in the retrospective the team adds "smoke test passes on staging" to the standard — recalibrating the finish line rather than leaving it stale or bolting the fix onto one story and forgetting it.

How it works

  • One standard, all items — the bar is reusable and item-independent, so it needn't be re-argued each time and can't be quietly lowered for a single inconvenient item.
  • Set independently of the container — done is defined by the standard, not by remaining time or budget, which is precisely what keeps work from expanding to fill the slot.
  • Binary and shared — an item either meets every clause or it isn't done, and the whole team owns the bar, so "done" is a checkable fact rather than one person's judgement.
  • Recalibrated on a loop — the standard is revisited (typically at retrospectives) and tightened or trimmed as the team learns what "good enough" actually requires.

Tuning parameters

  • Bar height — how demanding the standard is. Too low and quality leaks; too high and every item over-invests — the standard itself becomes institutionalised gold-plating.
  • Scope of application — one standard for everything versus tiered standards (per story, per release). Tiers fit better but multiply what has to be maintained.
  • Recalibration cadence — how often the bar is revisited. Frequent review keeps it current but churns it; rare review lets it drift from reality.
  • Add-versus-trim bias — whether recalibration tends to add clauses or is equally willing to remove them. An only-ever-adding loop is exactly how a done standard slowly becomes a gold-plating checklist.

When it helps, and when it misleads

Its strength is that it gives work a finish line existing independently of the resource container — the core of satisficing, stopping at good-enough rather than optimising without limit — and it makes "done" a shared, checkable fact instead of an individual verdict.[1] Its failure modes: a standard that only ever grows becomes the over-engineering it was meant to prevent; a standard too vague to check ("high quality") sets no real bar; and it is routinely confused with per-item acceptance criteria, so teams either duplicate the two or drop one. The classic misuse is treating the standard as untouchable and never recalibrating, so it drifts from what "good enough" now means. The discipline that guards against this is to keep the bar minimal and checkable, and to run the recalibration loop willing to remove clauses, not only add them.

How it implements the components

  • independent_sufficiency_criterion — the standard is the sufficiency threshold, defined independently of the container and shared across every item; it is the archetype's internal finish line made concrete.
  • finish_line_recalibration_loop — revisiting the standard (e.g. at retrospectives) is the loop that keeps the finish line current without letting it silently ratchet into gold-plating.

It sets the shop-wide bar but not the per-item scope fence or its acceptance record (elastic_activity_boundary / completion_evidence_packet — Acceptance Criteria Checklist), and meeting the bar is not itself the moment of stopping (stop_short_trigger — Done-at-Eighty-Percent Demo). The standard says what done means; those decide this item and this stop.

Notes

The Definition of Done and an Acceptance Criteria Checklist are complements that are easy to confuse. The Definition of Done answers "was this built well enough to ship anything?" and is the same for every item; acceptance criteria answer "did we build the right thing for this one item?" and are unique to each. Keep them separate: fold the global bar into per-item criteria and you re-argue it endlessly; drop the per-item criteria and a technically-"done" item can still be the wrong thing.

References

[1] Satisficing — Herbert Simon's term (satisfy + suffice) for choosing an option that meets an acceptability threshold rather than searching for the optimum. A Definition of Done is that threshold made explicit and shared: clear the bar and stop, rather than optimise without end. ↩