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.
A Twist for Tasks
There is a twist on the definition of done for teams who break stories down to tasks. When teams break down work, the question arises: Does the definition of done apply to stories or tasks?
As long as the team agrees, the definition of done can apply to either or both. Take the four-line bulleted definition I gave above. If applied at a task level, then JUnit and code reviews work fine. If there was something to show the product owner on the task, then sure, the owner can see it and approve it, but if it was an internal change (e.g., a database schema change), that check would be trivial. Similarly, if the task didn’t touch the third-party system, then there is nothing to check.
As long as the team talks through the various scenarios and comes to an agreement on how they will use the definition, then it should work. Again, the important thing is to have consistent understanding within the team.
I once met a team who went so far as to define two definitions of done: one for the task level and one for the story level. That might seem a bit over the top, but if the team thinks it helps and it doesn’t add to the administration burden, then why not?
Similar logic applies at the epic level, but because epics exhibit more variability, it seldom seems to be necessary to apply a definition of done at the highest level. Done for an epic is frequently a more subjective judgment. I certainly would avoid saying “All stories complete” for any definition of done that applies to an epic. Such criteria can lead to teams building stories that aren’t needed.
Working within Columns
A definition of done is normally, as the name implies, applied to work entering the final stage, namely, “done.” For teams using a visual board to track work, this means work entering into the final column of the board. But it is also possible to extend the idea of the definition of done across the board.
Another way of thinking about the definition of done is that it represents the preconditions for work entering the done state. Because nothing occurs between the previous work-in-progress state (board column) and the done state, the definition also forms the post-condition, or exit criteria, of the previous state and board column.
From here, it is an obvious step to think about the exit criteria for each state. Each column on the board can have its own definition of done. Few teams are so rigorous as to write such a definition for every state, but teams will frequently have “Acceptance criteria completed” as an exit condition on an analysis column.
Reviewing and Updating the Definition
Finally, the definition is not set in stone. Teams should periodically—quarterly, perhaps—take their definition of done and review every item. Over time, tightening the definition should lead to higher-quality code. Conversely, an overly long definition might be self-defeating, as people will eventually consciously or subconsciously skip steps.
In fact, given long enough, I would hope that the items listed in the definition become so normal and ingrained that people comply with the definition without even thinking about it. At that point, the definition becomes redundant; teams remove it to create an even lighter process, or they rewrite it with new items to encourage even better quality.