How to run a definition of done exercise
By Nick Butler in Agile on July 16, 2020
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:
- it’s the quality your customers expect
- it works together with the rest of your product
- there’s nothing left to do that might trip you up later.
What you want from your definition of done exercise
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:
- easy to read: use plain language so everyone understands
- concise: keep it short
- testable: avoid grey areas or vague standards
- realistic: focus on what is common to most work, not exceptions or aspirations
- relevant: keep it specific to your project.
To learn more about what makes a good DoD, check out this post:
Why run a whole-team definition of done exercise?
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.
Running the definition of done exercise
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.
When to run your definition of done exercise
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:
- In an early Sprint, come up with a draft.
- A couple of Sprints later, check how well the draft is working at a Retrospective.
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.
Who comes to the definition of done exercise
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.
What you need
You don’t need much equipment to run this definition of done exercise, just:
- a whiteboard.
How: The process
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:
- Why: Paint a picture of the benefits you’ll get as a team from having a DoD.
- What: Explain what the DoD is.
- How: Share the agenda and the process you’ll run through.
Here’s the process:
- Silent brainstorm
- Share out loud
- Sort ideas
- Sum up
- Make it visible
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:
- quality assurance
- anything that could come back to bite you if left undone.
Share it out loud
Everyone takes turns to read out each of their ideas, clarifying as required. They stick these up on the whiteboard.
Sort the ideas
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.
Sum up the clusters
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:
- easy to read
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.
Make it visible
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.
Putting your definition of done to work
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.