Week 28 Day 4: How to Write a Definition of Done That Actually Works

The best Definitions of Done fit on a single page. They use concrete language, not abstract language. 'Code reviewed' is better than 'quality checked.' 'All acceptance criteria verified by product manager' is better than 'stakeholder sign-off obtained.' Each item should be testable: someone can look at the item and determine whether it is true or false without subjective interpretation.

Here is the process for writing a Definition of Done that your team will actually use. Step one: gather input from every role involved in delivering work. The developer, the designer, the QA engineer, the product manager, the operations engineer. Each person adds the criteria that matter for their domain. The developer adds code review and testing requirements. The designer adds design review criteria. QA adds testing standards. Product adds acceptance verification. Operations adds deployment and monitoring requirements. Step two: consolidate and simplify. The initial list will be too long. Cut anything that is aspirational rather than essential. The test: if this item were not checked, would you ship the work? If the answer is 'yes, in most cases,' the item is aspirational. Remove it. If the answer is 'no, we would not ship without this,' the item is essential. Keep it. Step three: make every item binary. Replace 'adequate test coverage' with 'unit tests cover >80% of modified code paths.' Replace 'documentation updated' with 'API documentation reflects the new endpoint, including request/response examples.' Replace 'performance acceptable' with 'p99 response time under 500ms for the new endpoint.' Step four: pilot for two weeks. Use the Definition of Done for every piece of work that ships during the pilot. At the end of the pilot, hold a retrospective: which items caught real problems? Which items were always true and added no value? Which items were impossible to verify? Remove the useless items. Clarify the ambiguous ones. Step five: publish the final version and reference it in every project kickoff. The Definition of Done is only useful if people see it before they start working, not after.

The DoD writing process reflects principles from measurement theory and quality management. The binary criterion requirement implements what Stevens (1946) calls 'nominal scale measurement' -- the simplest and most reliable form of measurement, where items are classified into exactly two categories (done/not done). Research by Meyer (2002) on 'rater agreement in performance assessment' found that binary criteria produce inter-rater agreement rates of 90-95%, compared to 60-70% for multi-point scales, because binary decisions eliminate the ambiguity inherent in degree-based judgments. The essential-versus-aspirational distinction draws on what Kano (1984) calls the 'must-be/one-dimensional/attractive' quality model. Must-be requirements (essential DoD items) cause dissatisfaction when missing but do not add satisfaction when present. Attractive requirements (aspirational items) add satisfaction when present but do not cause dissatisfaction when missing. The DoD should contain only must-be items because aspirational items create the scope creep pattern described in Day 3. The pilot-and-retrospective approach implements the Plan-Do-Study-Act (PDSA) cycle (Deming, 1993), which is the foundational methodology for continuous improvement in quality management. Research by Taylor, McNicholas, Nicolay, Darzi, Bell, and Reed (2014) found that quality improvement interventions that included a pilot phase had 65% higher adoption rates than interventions that were implemented at full scale without piloting.