I always spend time during training classes thoroughly covering the concept of Definition of Done, sometimes abbreviated “DoD.” As a concept it’s fairly easy to understand and people generally see the value right away. And in practice, for many teams, this concept is the single biggest game changer for their speed, quality, and process. But I’ve also found that there are many ways to put the DoD into practice, and many techniques for using it during the course of a Sprint. I’d like to share some of those here:
Finally, there is really only one anti-pattern when talking about Definition of Done. And that’s cheating. Every time you bend the rules, say “good enough,” or forget about the DoD all together, you are taking on risk (and technical debt). I guarantee this will come back to bite you later. The Definition of Done is a really effective tool for ensuring quality, building trust with stakeholders, and producing a pattern of how the team creates product. Go up your DoD game!
- Manual Walk-Through. The most basic pattern is bringing up the DoD in the Sprint Review and manually walking through it for each PBI. This has the effect of putting focus on the importance of the DoD, and making it “front and center” for the whole team and stakeholders. This is very important as it establishes an agreement between the Development Team and the PO and other stakeholders that every PBI they show at a Sprint Review will adhere to the DoD. I highly suggest starting with this pattern to build that trust. However, it is a time consuming activity and quickly grows dry after a Sprint or two. Consider moving on:
- DoD checklist. A common technique I see on many Scrum teams is using the DoD as a checklist. The team either pasting that checklist inside each PBI As the team progresses on the PBI, they check off elements of the DoD that they’ve met. It’s now very quick to bring up the PBI in a Sprint Review and show that the checklist is complete.
- DoD as tasks. Another common pattern is to create a task for each element of the DoD. Similar to the checklist, it ensures we are focused on the DoD item by item. Tasks are sometimes easier to handle than an additional checklist, and most Sprint Backlogs have the concept of “task” already, whether it is stickies on a whiteboard or a tool like TFS.
- PO Review of DoD. If the team is in the habit of showing PBI’s to the PO during the Sprint, the PO can use that time to ask if the DoD is met. I’ve seen this spawn really good discussions mid-sprint, not only about the DoD but about the PBI’s itself, acceptance criteria, and other clarifications.
- Be sure to bring up the DoD in each retrospective. Ask what we need to clarify. Ask what we could add to make it more robust. Ask other teams what they have on their DoD that has helped them. I like to see the DoD updated each Sprint, even it’s it’s only a minor clarification, just to make it a habit.
Finally, there is really only one anti-pattern when talking about Definition of Done. And that’s cheating. Every time you bend the rules, say “good enough,” or forget about the DoD all together, you are taking on risk (and technical debt). I guarantee this will come back to bite you later. The Definition of Done is a really effective tool for ensuring quality, building trust with stakeholders, and producing a pattern of how the team creates product. Go up your DoD game!