The Definition of Done defines what is needed to call changes made to the product ‘done’ or ‘complete’. It can be helpful to think of it as a checklist that needs to be checked off at the end of every iteration or for every backlog item. As a checklist, the Definition of Done helps us answer the question “How do we know when we’re finished?”
Some Definitions of Done are more like a process description for how to complete work. I believe this kind of Definition of Done will never be as successful because it is trying to define the work to a level that just cannot be done for the kind of complex work which is suited to scrum.
We hire smart people for our scrum teams so that they are capable of figuring out how to get the work done. The Definition of Done supports their decisions by confirming an agreed end point and ensuring there’s no confusion about what the business needs to obtain value from the product increment. Every piece of work is unique and the Definition of Done as a checklist can provide the flexibility to make the right decisions during the process of delivering that work.
When the Definition of Done is a process, it implies we don’t trust our teams to make the right decisions on their own. Trust is an important factor if you want teams to make the best decisions they can and act in a trustworthy manner. There is also no way to be sure that a process-focus Definition of Done has been met without either trusting the team or putting ridiculous checks in place at all points along the process. In the end, trust is always easier.
Imagine the product increment is a pizza and the Definition of Done is a flavour on the menu. You can choose which ingredients you want to include but it’s not a recipe. The teams are expert chefs that work out the best way to put the ingredients together given the customer’s order. You wouldn’t go to a restaurant and try to tell the chef the steps to make your meal, so why would you do that to your development teams?
That said, the team is involved in creating the Definition of Done and the biggest challenge is agreeing on a level of quality and defining that agreement. The clearest definitions of those that show what we have in the end. Don’t focus too much on artefacts that prove things have been done (like overly documented test results), but instead focus on artefacts of value (like test results documented to the minimum level to help track down where bugs came from).
There may be process guidelines that back up the Definition of Done and provide the guidance for how to achieve each of the items but these are guides, not rules. Team members need the freedom to identify when the guidelines are not appropriate for achieving the final goal of a particular backlog item. In addition management or senior team members may mentor others in the best ways to achieve each Definition of Done item.
The most important thing that we must never lose sight of is what we are delivering to our customers at the end of every iteration. The Definition of Done is not a bureaucratic document for the sake of documentation. Like everything in Scrum, the focus is on delivering quality, working software every time.