By Nick Butler
Tags: Agile
In Scrum, the aim is to deliver a useful working product, Sprint after Sprint. To do this your team needs a shared understanding of what you mean by a working product. That’s where the definition of done comes in. In this post, you’ll learn how to run a whole-team definition of done exercise that gives you a DoD everyone understands and upholds. (Definition of done doesn’t exactly trip off the tongue so we tend to call it the DoD.)
The Scrum definition of done lays out what you need to do to make sure each piece of work is complete and release-ready. You need to make sure:
Effectively, the DoD is a checklist that defines what’s needed for an Increment to be releasable at the end of a Sprint. What you want from your definition of done exercise is a checklist that is:
To learn more about what makes a good DoD, check out this post:
Definition of done examples and tips
Sure, you could just present the team with a definition of done handed down from on high. It’d certainly be quicker. But it’s unlikely to work as well.
Creating your DoD collaboratively with the whole team — Product Owner, Development Team and Scrum Master — builds transparency and buy-in. The discussion helps everyone get straight what each item on the checklist means. Coming up with it themselves gives the team ownership, so they’re more likely to be accountable for meeting the definition of done. It lets you take advantage of the power of Scrum’s self-organising teams.
Having the whole team at your definition of done exercise is just the start. You also want to make sure that they’re all actively involved. That way you get the benefits of everyone’s experience, along with their engagement.
Ideally you’ll run the exercise early enough in the project that you get the benefits from the start, but not so early that people have yet to get a sense of the project.
If many of the team are new to the idea of a DoD, consider using a two-stage process:
This lets people see the definition of done in action, so you can inspect and adapt it.
Even if you come up with your DoD in a single session, you’ll still want to review it later. The definition of done should be a living document. If people start to let it slide, that’s a clear sign it’s time to check it’s still fit for purpose.
As noted earlier, you’ll want the Product Owner, the whole Development Team and the Scrum Master. As a rule, the Scrum Master facilitates the exercise.
You don’t need much equipment to run this definition of done exercise, just:
The process covered below is called affinity mapping. It’s a good way to get everyone involved, to generate lots of ideas, and to refine what you come up with as a team.
The facilitator explains the Why, What and How:
Here’s the process:
Working separately, everyone writes down ideas for items to include on your definition of done checklist, one idea per post-it. Any idea is a good one. You want to generate as many as possible.
If people are struggling, you could share some prompts or examples. But you want to avoid constraining people’s thinking or being too prescriptive.
You could prompt the team to think about things like:
Everyone takes turns to read out each of their ideas, clarifying as required. They stick these up on the whiteboard.
Then everyone comes up to the whiteboard and groups like with like. Put identical ideas on top of each other. Put similar ideas side by side. This creates clusters of related ideas.
Ask the team how they would summarise what each cluster covers and write the summary on the whiteboard. It’s OK to have singletons.
You now have the starting point for your DoD, so take a photo to capture what you’ve got so far.
Now list all the items on the whiteboard.
Ask the team if it covers everything. Check to make sure that each item, and the DoD as a whole, is:
Vote to choose those that need to stay. We use 3-2-1 voting a bit at Boost. Everyone gets to vote for 3 choices, giving their top choice 3 votes (as ticks or tally marks beside that item on the whiteboard), their next highest 2 votes and their 3rd highest 1. Rank them by popularity then decide where the cut-off is between keepers and rejects. Remember that the shorter the checklist, the more likely it is to be followed.
Next you rework each of the keepers until you’re happy it fits the bill. It’s easy to get stuck on details. If that happens, you might want to park that item till later. And, if you’re going to run a follow-up, you can leave your DoD a bit rougher because you’re coming back for a second polish.
Copy your refined checklist into a document and share that with the team. Stick a hard copy up on your project board and keep an electronic version somewhere everyone can get to.
Now you’ve put it together, you want to build the definition of done into the way you work.
When you’re first getting to grips with your DoD, consider printing out copies as a checklist and physically ticking off each item as you do QA. The Product Owner can do the same when they are checking stories that are up for acceptance.
Early on, when people report at daily standup that they’ve finished a story, it’s also worth asking the question: does the story meet the definition of done?
Before you even start the stories, make sure the Development Team factor in the DoD when they estimate the size. That way it’s less likely they’ll miss stuff due to time pressure.
Using the definition of done to ensure all your work is release-ready means you get maximum value from that work. Every Sprint you’ve got something you can put in front of customers with confidence.
Definition of done examples and tips
The definition of done and acceptance criteria: What’s the difference?
The definition of done and the definition of ready: What’s the difference?
