Scrum Artifacts: Definition of Done
The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
We’ve mentioned the definition of done a few times. The definition of done applies to each story in a sprint backlog. Declaring a story to be done is a means of verifying that all of its critical aspects have been completed based on the way each team works.
It’s vital for a team to have a shared idea of what done actually means for itself. Teams should create a written definition of done which they maintain as a checklist for every story they work on. This definition should be independent of the documentation for a specific story or project, because the definition of done should apply to the way a team works, independent of what they’re working on.
A definition of done is something the team should come up with together. It may be created during the first sprint planning, and iterated on during sprint retrospectives. A team’s definition of done may involve radically over time, as the team realizes during retrospectives what aspects of the process may need improvement.
It’s not a bad idea to publish the definition of done prominently. This allows people both on the team and outside the team to understand just how much effort is involved in completing any story. This document provides a reference point for questions about whether or not a proposed story is ready to be worked on. If it’s impossible for story to meet the definition of done based on the acceptance criteria, having a published definition of done can help the team make that clear.
Usually a definition of done includes a number of familiar expectations. For example, the code should be complete, the build shouldn’t fail, the test suite shouldn’t be broken, and the product should run as expected. Other points often included in a definition of done include peer reviewing code, writing new unit tests, code commenting, and updating product documentation. Different teams will have different requirements, and the exercise of creating a definition of done is valuable for helping the team realize what’s important for every story, not just certain stories.
Note: The Definition of Done Must Be Practical
While it’s important for a definition of done to be thorough, it’s also important that it’s practical. The definition of done must be achievable for every story. There may be practices the team believes should be followed for the sake of the codebase, but which are impractical given the constraints of the marketplace. Usually the engineers will argue for a more thorough scope, while the product owner may argue for a more streamlined approach, depending on the foresight of the product owner and the stability of the market. It’s up to each team to make their cases and come up with a definition of done that everybody can agree to before they start working.
