Definition of Done

A definition of done is a shared, explicit statement of the conditions that must be satisfied before any piece of work is considered complete. Unlike acceptance criteria, which are specific to an individual item, it applies uniformly across everything a team produces and encodes the quality standard the team holds itself to.

Its purpose is to make completeness objective and consistent. Without one, done means whatever the individual developer understood it to mean, which varies with time pressure and with who is asked. One person's done includes tests, documentation, accessibility checks, and deployment; another's means the code compiles on their machine. The variation is invisible until the consequences surface, typically as defects found late or as work that has to be revisited before it can ship.

A typical definition covers code review completion, automated test coverage at an agreed standard, all tests passing, accessibility requirements met, documentation updated, security considerations addressed, performance within defined thresholds, and deployment to at least a staging environment. The specific contents matter less than that they are agreed, written down, and actually applied rather than aspirational.

The most important function is preventing the quiet accumulation of hidden work. Items marked complete without tests, documentation, or accessibility remediation appear as progress while creating obligations that must be discharged later, usually under worse conditions. A team reporting steady delivery while accumulating this backlog is reporting an illusion, and the reckoning arrives as an unexplained slowdown some months afterwards.

It also protects quality under pressure, which is when it matters most and is most likely to be abandoned. When a deadline approaches, the pressure to relax the standard is intense and the relaxation is rarely explicit; items are simply marked done with parts omitted. Treating the definition as non-negotiable, and instead reducing scope when the schedule is threatened, is the discipline that distinguishes teams whose velocity is real from those whose reported progress is borrowed from the future.

The definition should evolve as capability improves rather than being set once. A team without automated deployment cannot include it initially, but should add it once the capability exists. Reviewing the definition periodically, typically in retrospectives, and raising the standard as practices mature, turns it into a mechanism for deliberate improvement rather than a static checklist.

The definition also has to be achievable, since a standard the team cannot meet under normal conditions will be quietly ignored rather than openly renegotiated, and an ignored definition is worse than a modest one because it removes the shared reference entirely. Setting it at the level the team can genuinely sustain, then raising it deliberately as capability improves, produces a standard that actually governs behaviour.

Where work genuinely cannot meet the standard, the honest response is to record the exception explicitly rather than to redefine done. An item shipped without a particular check, for a stated reason, with the remediation tracked, is a managed decision. The same item marked complete with the omission unrecorded is technical debt that nobody has agreed to and nobody will remember.

Because the definition determines what quality means in practice, it needs agreement from the people accountable for the consequences rather than only from the delivery team. In practice it is established within product development with the accessibility and experience standards drawn from UX audit criteria and the performance thresholds from web performance budgets, so that the standard reflects the whole obligation rather than only the functional one.