Teams that ignore the significance of owning and maintaining a DoD often times end up swimming in an increasing amount of technical debt and bugs. And yet the DoD has not yet become an established healthy practice of agile teams, but tends to be perceived as adding to unnecessary documentation. But is DoD only about so perceived useless documentation?
The Definition of Done is a list of criteria that teams must complete before a user story can be considered ‘done’. It ensures that everyone involved in product development speaks the same language, which gives clarity, transparency and fosters collaboration.
A framework like Scrum, if used right and for the right reasons, could help organizations save money, time and energy spent on irrelevant features. In Scrum, one of the most helpful artifacts that ultimately help you deliver the thing right is the Definition of Done, or a list of criteria that, if met, help you keep consistency throughout the product quality and engage everyone in working as a team towards the same goals.
So what is the problem that I encounter more and more? The problem is that often times, teams do not own a DoD and when they do, it is not a lively document that teams often reflect on. It may live somewhere as a list of steps that the team never really fully engage taking or it may be missing altogether. When working with teams who do not own a DoD, I ask them: what is the reason behind not owning a DoD? The answers that I often get are the following:
- We know what we have to do. It is in our heads.
- We almost never check it, we do not have time.
- If we took time for each of the steps in the DoD, we would probably never finish anything.
While these answers can take us back to deeper organizational issues, there are ways in which we can emphasize the value of creating and maintaining a DoD:
- By making the team aware of the value behind owning a DoD and making it transparent for everyone. This can be done by involving the product management and the developers in defining what is the minimum viable DoD and by reflecting on how the DoD can benefit the team and the product.
- By integrating it in the team’s planning and refinement meetings and using it to achieve consistency throughout our backlog. The Product Manager or Product Owner can use the DoD list to remind the team of what the Acceptance Criteria might include from it. Although the Acceptance Criteria are often enough to establish when a story might be done, a generic DoD might contain topics that do not apply for every user story, and yet are important to keep in mind (consider non-functional requirements, for example).
- By keeping it short and realistic enough so that it does not feel like a burden, but like a fair set of checks that help the team achieve the quality that they are aiming for. If the DoD is too long and hard to see through, it might demotivate the team from integrating it into their development routine.
It is best if software engineers define the DoD together with the Product Owner and in collaboration with other stakeholders (designers, data analysts, software architects, management). A Scrum Master or an Agile Coach can facilitate the process of writing and updating the DoD, but the main driver should be the team who owns it.
If teams do not openly share a DoD, it is hard for the old as well as for the new team members, for other technical teams and leadership to share an understanding of a stable and bug-free product. The reverse is a product that delights the customers by offering them a seamless, qualitative user experience and makes them always come back to it.