The Scrum Guide, while being a model of brevity, devotes an appreciable amount of space to the definition of “Done”. In my travels as a trainer or coach though, I often come across questions about the definition of done.  So, in this article, I’m going to examine it in more depth. I’ll provide some extra detail as well as reasons why your definition of “done” is so important and why you should invest time in creating, and maintaining it.

What is Your Definition of “Done”?

Let’s start with the first paragraph from the scrum guide 2013:

Understanding “Done”

Let’s dissect this a little bit.  The vital element I see here, is that everyone must understand what “done” means. Therefore, the language must be in terms that the entire scrum team can understand, which includes the product owner and scrum master, who may not be technical. This can present challenges and sometimes I like to do an exercise with teams to illustrate the issue.

Here’s one example.

An exercise I sometimes do, is to ask a scrum team to create an aircraft using just a single sheet of paper. I don’t provide any paper, I just establish some simple rules:

• The aircraft must fly between point a and b without touching the ground or any other obstacle, en-route (I will mark the points on the ground)
• As the aircraft passes point b, it must still be in the air and not have deviated more than two feet either side of point b
• The aircraft must be hand launched from point a by one of the scrum team

So far, so good. But, before they’re allowed to start work, I ask them to spend five minutes creating a definition of “done”. In almost all circumstances, this initially foxes the scrum team. There’s an initial belief that “done” is obvious and doesn’t need defining. Some of them, especially if you have any aircraft buffs, can get quite technical. Talk of flaps, elevators, ailerons, lift and thrust ensue. But, of course, this doesn’t help.

After a while though, someone usually realizes that the requirements I have given are a good set of acceptance criteria for the aircraft. This gets them thinking about quality and tests and so a definition of done starts to evolve, often describing the acceptance criteria provided, which everyone understands.

Hopefully team members will then start to think more broadly and consider things like the size of the provided paper. Have you ever tried to create a paper aircraft from a roll of wallpaper? How about a stamp? Do we need to consider flying the aircraft outside? Does it need to cope with rain? What about strong winds? Do we always use the same team member to launch the plane? Before we know where we are, the team are scribbling furiously and five minutes seems way too short.

The object of this exercise is to move people out of their comfort zone and consider describing “done” in terms that the whole scrum team can understand. It’s an effort well worth making. Not only does everyone understand what “done” means, you’ll likely achieve greater commitment because of the greater clarity and, as we all know, transparency is a good thing.

There’s also a side-effect that’s really important. When faced with the task of creating a definition of “done”, our minds go blank. It can take a while to get in the groove and start producing something useful. In my experience, not all scrum teams allow themselves the time to do this and that’s a mistake.

The Far-Reaching Consequences of Your Definition of “Done”

There’s another section in this first paragraph of the scrum guide that’s worth mentioning. It describes how the definition of “done” varies significantly per scrum team. At first glance, you might think that each scrum team has it’s own independent definition but that’s not the full picture. A section in the next paragraph states:

What’s really being described here is a minimum standard that each scrum team must meet. Teams remain free to add their own extensions to this minimum set. Be wary though, because the common definition you construct must be realistic enough to be implemented by all scrum teams. There’s no benefit in building an unattainable ‘ivory tower’.

Our second paragraph contains another interesting section:

On most scrum teams, this statement is reflected in agreement on the work integration standards. So we’re reining in the independence of the definition of “done” again. As before though, we need to be sure that the definition we create is achievable by all teams, and understood by all teams.

To summarise this section, every scrum team has its own definition of “done” but it may well have a minimum set of standards established by the organisation or agreed with other teams working on the same product.

Planning and Estimating

You’re probably aware that your definition of “done” has an impact on your estimating, right? Well, not entirely. In reality, it’s a little more subtle than that.

If you use relative size estimating for your product backlog items, your estimating won’t need to change. The reason is that your definition of “done” applies to all product backlog items, so the size of one item, relative to another, will probably remain the same.

However, at the task level, where most development teams estimate in hours, the definition of “done” is very likely to affect your estimates. For example, if you add in a new requirement that all new code must be tested prior to being integrated with other development team’s work, you’ll likely add a whole new task for every product backlog item to reflect this.

The net result here is that while estimating at the product backlog item level isn’t affected, it’s probable that, all other factors remaining the same, the velocity of the scrum team will drop to reflect the extra work being required by the new definition of “done”.  This will definitely affect planning. In fact, it will affect planning at all levels: Sprint Planning, release burndown and product burndown to name but a few.

Product Increment

The scrum guide clearly states the purpose of a sprint and the intention of the definition of “done”:

Okay, that doesn’t sound too hard. We describe a definition, make sure all the work reaches that definition, and we’re done. Not so fast. There’s more to come:

Your definition of “done” then, must declare all the work necessary to make your product increment potentially releasable. This is a significant challenge. Hidden within these two sentences is the expectation that no other work remains.

Our product increment must be production ready. It’s been compiled, reviewed, integrated, tested, been through integration testing, regression testing, product owner assessment, stakeholder review, deployed to pre-prod etc. Nothing else needs to be done. There’s no user acceptance testing, no handover to QA, no passing to the release team. Because all of the work has been done, within the sprint.

Sometimes, when I work with scrum teams, I like to point out these requirements succinctly. I describe how, at a sprint review, the product owner must be able to simply push a button, to put the increment live. This can concentrate the mind wonderfully. Now, we get away from abstract ideas in the scrum guide, to real implementations on the ground.

How does your definition of “done” match up to these requirements? While you’re mulling that over, here’s one final thought from the scrum guide as regards the product increment:

Evolution of the Definition of “Done”

Your definition of “done” is a living, evolving thing. As a scrum team gets better at what it does, it will identify opportunities to improve their quality and/or performance. This can often mean a change to the team’s definition of “done”. This is a healthy thing.

But do be cautious. A definition that runs to reams of paper is likely to be as well received as a legal ‘Terms and Conditions’ disclaimer. That is, it won’t be read and it certainly won’t be acted upon, rendering it useless.

Let’s leave the last word in this section to the scrum guide again:

Beyond the Definition of “Done”

Hopefully, the above information has highlighted some of the more important parts of the definition of “done”. I believe it has more benefits than those listed in the scrum guide though.

Consider scrum preparation. The pre-game. That is, the preparation you do before starting scrum. (Please don’t call it sprint zero. It’s like fingers down the chalk board for me and most of my fellow scrum trainers).

During scrum preparation, it’s common for scrum teams to go through activities like:

• User story workshops
• Creating a product backlog
• Estimating
• Agreeing business value
• Creating a product vision

There’s usually a lot of interest in deciding what technology we use. Teams consider things like programming languages, databases, technologies, 3rd party components and so on. Consideration is given to design and architecture. Most times, some thought is given to the definition of “done” too. But, in my experience, usually not enough time is allocated to this vital task.

I’ve come across large organisations whose response, when asked to produce a definition of “done”, was to ask if there were any template versions they could use, just to get started. I sense a lack of commitment when this happens (I’m British – we’re big on understatement). Setting your definition of “done” prior to starting work, is the equivalent of declaring your minimum quality standard. Don’t skimp here. It’s important.

If you’ve come across broken windows theory before, you’ll already know that a poor quality code base will simply attract all the wrong kind of behaviour. It will certainly attract technical debt which is a corrosive eating away at your software. These are all bad things that get compounded every sprint.

But you’re a responsible organisation. You’ll address this technical debt, won’t you? Here’s what Ken Schwaber, one of the co-creators of scrum, has to say on the topic:

In case you still need convincing, consider this situation. If I carefully pass you a ‘thing’ that is of superlative quality and ask you to refine it, how would you respond?

Contrast this with me throwing you the exact same ‘thing’ that was constructed by the lowest bidder, ruthlessly honed down to the bare essentials with no expense uncut, displaying the effects of risible quality control and a propensity to fall apart at any minute, and I ask you to refine it, how do you respond now?

So please, be under no illusions. Your initial draft of your definition of “done” is important. Treat it with the respect it deserves.