A common reason for disagreements is differing definitions. I once had a discussion with a friend about egoism and people’s ability to do truly altruistic acts. After an hour though, we suddenly couldn’t agree more. That was when we decided to define egoism.
Defining what done means is essential of exactly this reason. If you don't know what people mean by "done", how do you have meaningful conversations about progress and the state of work? How can you be confident when asking for estimates?
Scrum presentation Zen of Scrum.
The Purpose of a Definition of Done
The DoD (Definition of Done) serves three purposes:
- Enable time estimations. If you don't know what people mean by done asking them for an estimate is pointless.
- Avoid misunderstandings. When having conversations about progress, work being done, and so on, shared definitions help avoid misunderstandings and disagreements.
- Assure quality. The DoD ensures quality and helps avoid technical debt by including test cases, refactoring, code documentation, and so on.
The DoD also helps finishing stuff and right shift them to the Done column. With no definition of what done means, it's easy to end up with the five more minutes syndrome, and gold plating.
As the DoD evolves it can also help improve how backlog items are written. If, for example, the DoD states that the acceptance test shall pass, you're going to need a well defined such test, right?
The DoD is dynamic. It should evolve as teams learn more. It should also be shared with stakeholders and other teams. This ensures transparency and simplifies communication.
A lowest common denominator of the DoD can even be the same across teams, if not the complete definition. The level of sharing also depends on at what level the DoD is used.
Different Definitions at Different Levels
It is possible to have different definitions of done for backlog items, sprints and releases.
For example, a DoD for backlog items might include unit testing and source control management while the release DoD might include updated manuals and performance testing.
Mitch Lacey includes some examples of DoD's at different levels in his article "How Do We Know When We Are Done?".
In the article "What is Definition of Done (DoD)?" Dhaval Panchal makes a good point about at what level to place different activities:
Ultimately, the decision rests on the answer to the following three questions:1. Can we do this activity for each feature? If not, then
2. Can we do this activity for each sprint? If not, then
3. We have to do this activity for our release!
That’s it for now, as I’m off for a week of hiking in the Swedish mountains (fjällen).
The next post in the Zen of Scrum series will cover the product backlog and user stories.