An Exercise for Defining Done for Scrum Teams

In this post, I’m going to share an exercise you could try for helping a team start their journey towards a clear and shared definition of what it means to done with a feature in a software product. I’m looking at this from the perspective of agile development with Scrum, but my guess is you can use this even if you’re not using Scrum. I’ve taken a core exercise I’ve used many times to help teams form a first definition of done, and combined it with some debriefing practices I’ve learned over the years. If you want to use this exercise, go ahead. If you run it a couple of times, you’ll be able to improve on it: then I’d love to learn about how you improved it.

Scrum has taken some flak because many perceive the model as lacking a clear focus on solid development practices such as automated unit testing, refactoring and code or design quality in general.

It’s true that Scrum does not supply us with a detailed definition of exactly how software should be developed. What we get instead are some general admonitions. From these, we need to create our own set of practices that are suitable in our specific context. Here are the general rules that Scrum gives us:

• Every sprint should end with a done product increment
• Done means having something potentially deployable, something of business value
• Potentially deployable implies a well designed and well tested solution, documented with user manuals if those are needed for the product to be usable

As a quick sidenote, let’s explore why we like to say “potentially deployable”, rather than “deployable”. Adding that extra word – potentially – gives us a useful, albeit sometimes risky, window of flexibility. What it means in practice is that, if by the end of the sprint we realize that we could gain from deploying, we should be able to do that deployment with just a little extra work. In an ideal world, we would be able to deploy directly – and some companies can do this. However, a company just starting out with Scrum probably cannot do this. They need to improve the way they develop software until they can be “more done” every Sprint, thus acquiring the ability to capture potential business opportunities by deploying early and frequently. The risky part: some will be satisfied with building “good enough” product increments, forgetting that in the long run, insufficient quality very easily turns into terrible quality.

How does a team move from Scrum’s general definition of done to a detailed description of what done means for them? The team can get there over time, by inspecting and adapting every sprint. If for example, we notice that planning meetings take too long and are fraught with hostile discussions, we might want to explore if we really agree on what it means to be done with something.  If you and I are in the same team, and your definition of done is “if it compiles, ship it” and my definition happens to be “refactored, well designed and thoroughly tested”, we’re bound to have frustration and misunderstandings. If this is the case, a clear and shared definition of done will be very helpful.

Let me describe an exercise I often use in my classes and workshops. It builds on several ideas to help a team get going with their work on defining what done means to them. The ideas I’ve built the exercise upon include these:

• When asked if we agree on something, we sometimes say yes just to avoid exposing a conflict, so we need to find a way to safely expose disagreements that prevent us from working well together
• Agreeing on a definition of something is often hard work, so we could use some help to get going and to avoid some common pitfalls
• Simply stating that you agree is not as powerful as when you actively participate in the discussion, so we can use a setup that entices as many as possible to step in and actively participate

Over the years, I’ve tried some different approaches to this. Let me give you a step by step description of the exercise the way I myself will do it the next time I use it. I think it will work well, because the core of it is about really activating participants and in getting the discussion going in an effective and safe way.

Preparation

1. On a set of regular size pages, type out a list of items that might be included in a team’s definition of done, such as: “Code is refactored”, “Automated unit tests written”, and so on. Take care to express things clearly. I have a set of four or five pages with things. Some of them are quite uncontroversial (“Code written”), some are things that typically need to be discussed and refined (“Full performance test run”).
2. Format the pages so that each thing stands on its own line, a couple of centimeters (an inch) high, with large type. Add horizontal separators between each line, so that the sheets can easily be cut into slips.
3. Add an extra page with blank lines that the team can fill in themselves
4. Print these pages and bring them – and a couple of scissors – to the workshop.

The Exercise

1. Invite the team and set the room up so that everyone can work together comfortably around a large table.
2. Explain that you are about to engage in an interactive exercise together, and that the purpose of it is to see if we can find a shared definition of what being done with a product increment means to this specific team in this specific project. If the team is new to Scrum, a mini-lecture about how defining done fits into Scrum’s iterative and incremental way of working will also help here.
3. Hand out the sheets you prepared, and ask the team to cut them up into strips with the scissors you supplied. I prefer letting the team do this work, because doing something physical is an nice way for the them to slowly “warm up” for the hard parts of the
4. Explain that the blank slips can be used to add missing items, if needed.
5. While the team is doing the cutting, prepare a flip chart on the wall. On this flip chart, draw a vertical line down the middle, so that you get two columns of equal width. Over the left column, write the heading “Every sprint”. Over the right column, write “Before release”.
6. Wait for the team to end their cutting, then ask for their attention. Explain the flip chart. Tell the team that you want them to take this flip chart and put it on their table. Say that you want them to sort their strips into the two columns. In the “Every sprint” column, they are to put every item that they agree should be performed by the team during each and every sprint. In the other column, “Before release”, they are to put items that they think are important, but that for some reason cannot be done in every sprint, but that definitely must be done before the product can be shipped out. There is typically no need to go into why something might end up in the “Before release” column, but if the question comes up, briefly explain that for technical or economical reasons, it can sometimes be hard to fit some things into the sprint, and that this may or may not be true for the current team.

7. Explain that what comes next is very important. Once you have the full attention of the group, reveal that they will do the sorting under complete silence. This is usually quite surprising. Tell the group that they are to work in silence, until it is absolutely impossible to keep working silently. When this happens, but not before, they can start talking to each other.
8. You also need to explain how the participants should handle differences of opinion during this part of the exercise. Explain that all participants have the right to place any slip in the place they think it should be. If anyone sees a slip that is in the wrong column, they can just move it to the right column. If you see someone moving a slip you just placed, just move it back again. You’ll notice if some slip keeps moving back and forth a number of times. If that happens, just place it on top of the line separating the columns, and keep working on some other slip. Don’t start talking when this happens, just keep going. When everything has settled down and you can no longer work in quiet, that’s when you can start talking about how to handle those hard to place pieces.
9. Sit back and watch the team get to work. It’s quite fun. Take this time to practice your skills of observation – look at expressions, gestures, movements and think about what they might mean. If someone starts talking too early, gently remind them to work in silence for just a few minutes more, until most pieces have fallen into place.
10. After some time, the team will notice it can get no further unless they start talking to each other. When this happens, most uncontroversial pieces have typically found their place, even though you can be sure there’s still no agreement. Depending on the team, you might need to facilitate this lightly. One way to do that is to ask some questions, like “I notice you’ve placed this slip here (point to a slip) – how did you decide on that?” Some teams naturally take to discussing, others need more help to get started.
11. Let the team take its time working on the sorting. Remind them that we’re searching for a shared and usable definition of done, something that they could potentially use in their current project right away.

The Debrief

1. With the slips sorted into columns, hand out some tape and ask the team to fasten the slips to the flip chart they’ve been working on, then to post the whole thing on the wall.
2. Ask the team: “You’ve created your first definition of what it means to be done with a product increment in a sprint. What are your thoughts now?”
3. Write down the reflections that come up, exactly as they come up, on an empty flip chart.
4. Next, write the heading “Suggestions” on a blank flip chart, then ask the team: “What are your suggestions on what you as a team should do next?”. Clearly explain that we’re currently only after ideas, that we’re not deciding anything yet.
5. Help the team do a silent brainstorming to identify as many suggestions as possible . My experience is that a silent brainstorming results in more and more-varied ideas. To do this, just hand out sticky notes and ask participants to write one suggestion per sticky note. Set a time for this, perhaps five minutes, or maybe ten. I usually go with five, then ask if more time is needed when those five minutes are up. When the time is up, let those still writing finish their notes, then ask participants to take turns posting and reading their suggestions.
6. With all suggestions up on the wall: do a quick dot voting to gauge the group’s thoughts about the suggestions. Ask each participant to place exactly five voting dots on the suggestions he or she thinks has the greatest potential in helping the team perform better. Explain that they can place the dots any way they want, all on one suggestion or distributed over several sticky notes. Explain that this still does not mean we’re deciding anything – we’re just trying to get a feel for the group’s overall interest in the suggestions.
7. When the suggestions have all been posted, write the heading “Next steps” on a fresh flip chart and tell the group that the time has come to see if they can decide on some next steps to take. Ask the group: “Can you agree on some next step?”. Someone typically shouts out one of the previously posted suggestions, or something that is a synthesis or rewording of one of those suggestions. Help the group formulate the next step as a clearly stated action. Ask the group if they agree that doing this action is desirable. Use thumb voting if needed: thumb sup means agree, down means don’t agree, sideways means “I don’t care, so I’ll go with what the majority decides on”. If someone shows a thumbs down, work with them to modify the suggestion or create a new one, until agreement is reached. If no thumbs are pointing down, the group has decided.
8. Ask for more next steps, until you have enough to see that the team will take some clear next steps to keep moving with the work they’ve just done on defining done. If everything goes well, the team will suggest activities that relate to incorporating the new definition of done into the daily work. If things go less well, they might not – but this is also information, and you should be glad that it comes up now and not later, when you’ve tried to build a product without first agreeing on how to work together. Don’t be surprised if the team comes up with really inventive and ambitious ideas, and choose to act on them – my experience is that this happens more or less every time I work this way with a team.

The first definition of done agreed upon by a team in an exercise like this will not be the final one. Whatever you do, don’t print out and laminate this definition. As a team learns more, builds more capacity, and learns to work better together, they might realize that they can improve their definition of done. A team using Scrum then implements these improvements, and it does this in a way that ensures that the whole team is in on the changes.

A word of caution. You might think this whole exercise seems like a waste of time. After all, how hard is it to create a solid definition of done and just hand it to the team? In fact, if you’ve been in the software business for a few years, that’s not hard at all. However, creating that list does not mean that the team will use it. Defining done is more about finding consensus than it is about listing an optimal set of practices. I’ll take a less impressive but widely shared definition of done over an ideal but ignored list any day. If we know where we stand, we can always improve from there.