Hang around teams working on agile projects and you’ll frequently hear people talking about “done” and “done-done.” What they mean is that work not only is completed, but also complies to the common standard known as the definition of done. The work is both “done” and “done” to an agreed set of criteria.
The definition of done is an informal checklist that the team agrees applies to all pieces of work. The whole team is responsible for approving and writing the definition of done and applying it to every story they work on.
When I say it’s an informal checklist, I mean there is no paperwork or formal sign-off process associated with a definition of done. It is an aide memoir, a reminder, and an agreement among team members that before anyone attempts to mark a story as done, it will pass all the points on the checklist.
One team I worked with had four items on the checklist:
- JUnit tests written for code
- Peer code review conducted
- Product owner approved
- Interface to third-party system double-checked
The team wrote this list on their team board, where it was clearly visible to everyone. Before any card moved to the done column, the team members would ask themselves: Have I done these four things?
Acceptance Criteria or Definition of Done?
Teams sometimes get confused between the definition of done and acceptance criteria, or they worry about the interplay between these two completion tests.
A definition of done is not an alternative to the acceptance criteria; it is a generic baseline for all stories. Each story brings its own special acceptance criteria. In effect, every set of acceptance criteria has an unwritten first item: “Conforms to the definition of done.”
Or, to put the other way around, every definition of done has as a implicit line item: “All acceptance criteria pass.”
Perhaps surprisingly, I frequently meet team members who do not agree on what constitutes done! For example, one developer will only push a card to done after a code review, while another will not even ask for a code review. Without a general agreement on what done means, how can a team ever hope to be consistent?
This is where a definition of done helps. This isn’t something imposed from outside or above; it is important that the definition is the result of team involvement and agreement.
The aim of both acceptance criteria and the definition of done is to improve the quality of the code produced. Research—and programmer intuition—consistently shows that higher-quality code saves time and, therefore, money. When code is low-quality is must be repeatedly tested, fixed, retested, and fixed again. Time increases, costs escalate, and schedules disintegrate in the face of poor quality.