Techniques for using the Definition of Done (DoD)

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:

1. 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:
2. 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.
3. 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.
4. 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.
5. 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!

Sprint Review Technique: Videos

File this one under: “how do you do Sprint Reviews when you have lots of teams?”  Indeed, the traditional presentation format gets long, boring, and ineffective when you have more than a handful of teams presenting at a Sprint Review.  From the point of view of an executive, this is exponentially true if you are overseeing many different products.  The Video Sprint Review technique can help. 

I learned about the Video Sprint Review from Aaron Bjork at Microsoft, and if you skip to the ~40 minute mark of this video you can hear it too.  Basically, with hundreds of developers, it doesn’t make sense to do a presentation style Sprint Review every few weeks.  So they’ve adopted a pattern of “Sprint Mails.”  Each team sends out an email at the beginning of the Sprint with what they have planned, and at the end of the Sprint with what they have DONE, along with a video of the working software.  This email goes to all the teams and all the management:

An example "Sprint Mail" from Microsoft.  Sprint Plan on the left, Sprint Review including a Video on the right.  Screenshot from the linked video. 

A few things about this really work for Scrum at scale.  And there are a few dangers.  

What works is that it’s actually feasible that a single stakeholder could review dozens of videos each Sprint.  Whereas a traditional Sprint Planning meeting would take hours and hours, these short videos deliver information in concentrates bursts.  The constraint of a 2-3 minute time-boxed video encourages the team to show the most important stuff in a highly organized and distilled way.  This scales well, both in size and in geography – much easier to work with a distributed team using this technique. 

A few things to watch out for, besides the urge of creative folks to make Hollywood quality productions, as Aaron points out in his talk.  This technique is largely unidirectional.  The teams are telling the stakeholders what they’ve done.  It’s incumbent on the stakeholders to speak up, and actively search out the teams and give feedback about what they’ve seen in the videos.  This takes a special kind of culture, and managers are going to have to constantly work on creating this environment.  The closer stakeholders and teams work together, the better product you’ll end up with.  

Another thing to watch for is the Definition of Done.  We need to be extremely clear on what DONE means, especially when it comes to deployment environments, as a lot can be concealed in a video.  Perhaps a good addition to these Sprint Mails would be a DoD checklist, or starting the video with a quick review of what DONE means.  

With these things in mind, I hope you consider adding this technique to your bag of tricks.  Video Sprint Reviews can be very effective at scale, with many teams, and with many products.