Definition of Done 101

The Dictionary Definition of Done

Scrum does not tell us the exact Definition of Done… rather, it gives us some principles to work from.

Consider: where does the definition of a word in a dictionary come from?  Normally, people use a word in real life, and then the authors of a dictionary document that usage.  The dictionary definition follows behind the real use of the word.  We then use that dictionary definition but only to clarify what we mean – to create transparency and understanding.

The Definition of Done is not something that’s imposed by the organization in Scrum (at least not entirely). It’s not something that’s dreamed up by the team or the Product Owner, it’s not a standard that the team must live up to and it’s not bureaucratic.

Instead, the Definition of Done is kind of like observing reality. What is the team actually calling doneness when it says “we’re done some work now.”

There’s a couple important things that we need to keep separate. The Definition of Done is not about scope, so it’s not about how many product backlog items you get done in a sprint, for example.

It’s also not about overall project doneness. The Definition of Done is not the same as acceptance criteria. You may use acceptance criteria in your Scrum teams and it’s actually kind of the other way around. Acceptance criteria may be part of the Definition of Done but not necessarily so.

Identifying Dependencies

One way to illustrate it is with a very simple diagram that shows dependencies between a Scrum team and other parts of the organization or their work ecosystem. So let’s say they’re doing one-week sprint sprints and in many large organizations, there are lots of dependencies. It’s very hard to create true cross-functional multi-skilled teams with no dependencies.

The reality is you have a Scrum team doing sprints, trying to get stuff done. And as far as the team is concerned, they are getting stuff done. So so let’s look at some of the dependencies that might exist.

Let’s say there’s a subject matter expert (SME) who lives somewhere outside the team in the organization and, whenever the Scrum team needs a question answered, they send an email or do a phone call or whatever and there’s a dependency there. They’re not a member of the team. They don’t show up at the daily Scrums. They never come to the sprint review or planning, but when a question is asked, the subject matter expert always responds in one hour or less. And, most importantly, they are really good collaborator for the team and their answers are usually sufficient.

So, given one-week sprints and the kind of pace that that might imply, is this dependancy a huge problem or is it okay? It’s okay. As a Scrum Master seeing this, you wouldn’t need to start insisting that this SME needs to be on your team. There’s no reason to say “hey so and so, you’ve got to come to all the daily Scrums.” It doesn’t make sense. There’s no problem there really.

Problematic Dependencies

But another kind of dependency that is quite common in larger organizations is a dependency on a database admin group somewhere. Often in the hinterland, there is an anonymous email address that you send requests to and they have a service level agreement of three weeks for any kind of request: approvals, schema changes and production data updates. Anything.

And is this a problem? Yeah, it sure is. Right now, the Scrum team is still working. They’re still doing whatever they’re doing. But there’s always a significant lag for the database related stuff. And this is the kind of dependency that, as a Scrum Master, you would want to make transparent and you would want to try eventually to improve.

How could you improve this so that it worked with this Scrum team? Well, potentially there’s a human being over there that you can pull into the team. That’s not often sustainable but sometimes it can work.

Another option is you change the service level agreement. And believe me, this is the most realistic possibility. Get rid of three weeks and replace it with what would be reasonable under the circumstance. Maybe two days instead.

But that is still hard. You’re still going to have to work with upper levels of management to get it in place. But it is possible.

Another option: possibly you already have someone on the team who’s familiar with the database work or who’s willing to learn and so you improve the skill on the team to include DBA skills. Again, from a tactical perspective, there’s often a willingness and an ease to doing this but bureaucratically, this can be really challenging because the database is the “keys to the kingdom”.

I don’t recommend this in normal circumstances, but sometimes you just bring the database into the team. You just say “screw the DB team. We’re doing it ourselves completely.” Again, not always possible, but in certain extreme circumstances, that might be necessary.

Done and Doner

Whichever one you choose, the intent of these changes is to improve the team’s Definition of Done. Before any of these changes, database work is not part of the team’s Definition of Done. It’s not done by the team. It doesn’t occur within the sprint that it’s needed to occur in. And therefore, it’s not part of the Definition of Done.

And, after successful changes, database work becomes part of the team’s Definition of Done.

Another example is a vendor. And often there’s an intermediary here which is legal. You might need the vendor but you have to go through legal or procurement or whatever it is. The thing is, that legal might say “we do fixed scope, fixed price, fixed date contracts.” You’ve got a different obstacle there.

From your perspective, often this is waterfall. They’re going to deliver something in four months, and you’ll just get it. And it’ll either work or it’ll suck, and if it sucks, you’re going to wait another two months because of how the contract is set up.

A lot of the same kind of ideas can apply to fixing that situation, but you’ve got the added complication of legal or procurement in there.

Interdependent Teams

One last example: let’s suppose that this particular Scrum team is doing work on the front end of your application, or system or product, and there’s another Scrum team or multiple Scrum teams that are back end Scrum teams.

Now you have something even weirder. You have a product backlog sitting between both teams and you don’t know if or when the work you need them to do is going to get done because that’s not the nature of Scrum. We don’t guarantee anything.

If you’re lucky, your team makes a request and the Product Owner of the other team puts it on the top of the product backlog. So sprint N you make the request. Sprint N+1, the team works on it. Sprint N+2, you can use it. In one-week sprints, that’s not terrible. But in one-month sprints, that’s a lot of delay.

The proper response to that is to split both teams in half and make a new team that has front end and back end. And likewise, another team that has front and back end. That’s the additional “technique”.

There are of course other scenarios for dependencies. But these are the most common and all of it is to say that, as a Scrum Master, your job isn’t necessarily to fix everything. You have to serve the organization and the team.

But the way that you do it is through transparency. So you need to make the current Definition of Done transparent. You have to clearly articulate what it is inside the team, every sprint.

Done vs. Potentially Releasable

A lot of times, the Definition of Done is a checklist and what you’re trying to do is to understand the gap between the Definition of Done and what it means to be potentially releasable.

What’s interesting is that the concept of potentially releasable is a standard. It is determined usually at a corporate level as well as at a product level or system level. And that standard is often a very long list. It’s going to include things that are obvious:

• development
• unit testing
• functional testing
• integration testing
• security testing
• performance testing
• automation
• permissions
• quality standards
• user acceptance testing
• a log
• accessibility
• localization
• compliance
• audit
• sponsor sign-off

But the question is what is the Definition of Done currently? This is a matter of observation. You look at your team, you look at the sprints and you say “out of this big long list, what stuff actually happens within the team every sprint?” according to the skills, the authority, whatever. And now, the team needs to figure out how to improve this.

For example, let’s try and do integration testing. In the sprint retrospective, the team would have an opportunity to say “okay, this integration testing is really important for us to have. This is a major obstacle. How can we bring that into our sprints? Well we don’t have a continuous integration system and we don’t have ‘mocks’ for all our external systems so let’s let’s try and set that up.”

So here’s the question: after they make that decision, when do you get to put a checkmark on the Definition of Done? When do you get to call it “done”? The answer is when they can do it every sprint. So, back to integration testing, maybe they get it in at the next sprint. But maybe it takes five sprints before they set up all the automation and it’s only after five sprints that they’re able to do it every sprint. That’s when they would get to put the checkmark here and say “okay, we’ve expanded our Definition of Done.”

Slower Now, Faster Later

Now, this additional integration testing within the team actually means the team will get slower, because now they’re doing more work. Now they’re taking on that role. But actually, in the long run, it’s making the organization faster because they have less of an external dependency or they’re producing less defects.

Overall, the productivity of the team has gone up but it may seem like they actually have more work because writing integration tests IS more work. But we’re not doing more work just for the sake of doing more work. We’re doing it because it makes us faster in the long run.

Generally speaking, if your product backlog items represent customer recognizable value then most product backlog items will need all of the Definition of Done and ultimately, all of the standards for potentially releasable.

Product backlog items should never be technical items. A product backlog item is always something that a customer wants and cares about—a feature or a benefit.

In most organizations, when they first try and use the Scrum framework, they don’t really use it properly and they insert it within an existing waterfall process. They’ll have upfront waterfall stuff, then sprints in a development phase and then back in waterfall again. And one way to think about this is that the team and the organization have a very immature Definition of Done.

The Scrum Master and the Definition of Done

As a Scrum Master, one of your jobs is to improve the Definition of Done. We talked about some of these ideas already: improving the skills on the team, increasing the authority of the team, automating stuff.

One thing is often forgotten though, which is really important: sometimes there’s just stuff you’re doing that you shouldn’t do. Get rid of the waste. Processes and tools, comprehensive documentation, contract negotiation, big plans. That’s all waste. That doesn’t help your customers with their competitive advantage. It doesn’t help you deliver faster. Actually, it’s the opposite.

Over time, your team and your organization matures and you get to that ideal end state where every sprint is an independent project. As a Product Owner, your business chooses whether to deploy or not, whether to release to the marketplace or not, every sprint.

If the Product Owner at the end of the sprint says “wow, this is great!” and the customers say “this is awesome!” then all you do is you press a button and poof, it’s magically automatically in the hands in the marketplace, in the hands of your users and customers.

That’s the Definition of Done.

Check out this short video for another explanation of the Definition of Done.

This article was adapted from a transcript of a Certified ScrumMaster class that Mishkin taught in Toronto, ON.

If you found this useful, please consider contributing with our
“Value for Value” model.