Definition of done examples and tips
By Nick Butler in Agile on May 06, 2019
Of all the Scrum artifacts, the definition of done tends to get the least love. And that’s a pity because checking that all your work is of releasable quality is a powerful way of delivering the benefits of Scrum. So, here are a bunch of definition of done examples, tips and techniques to help you get these benefits.
The definition of the definition of done
According to the Scrum Guide, you use the definition of done to assess when work is complete on the product Increment. It ensures members of the Scrum Team have a shared understanding of what it means for work to be complete. Here’s what the Scrum Guide has to say about the definition of done.
So the definition of done makes transparent your team’s shared understanding of what needs to happen for any piece of work to be completed to a useable standard. Think of it as a checklist that defines what’s needed for an Increment to be releasable at the end of a Sprint.
Potentially Shippable Increment
What makes an Increment releasable then?
You’re after what’s sometimes called a Potentially Shippable Increment (PSI). You might not ship or release the product but you can if you want. Or you can beta test it with a selection of your customers.
This means you must have no work left undone. Because even if you don’t ship now, any undone work can trip you up when you do. And coming back to past work is harder than doing it while you’re in the zone.
The Increment is all your previous work on the product plus the latest Sprint. So all this work needs to fit together. For a software project, this might mean your definition of done specifies that your Continuous Integration build is passing. For a non-software project, such as creating a set of marketing materials, it might mean removing outdated versions of the materials from the shelves.
The PSI also needs to be of a standard you can stand behind: something you can confidently put in front of your customers. For a software project, for example, you’ll want quality assurance checks like code reviews completed. For a non-software project like the marketing materials, you’ll want to get the text proofread.
The definition of done gives you the strong base you need to keep delivering value early and often. It does this by making use of the three pillars of Scrum: transparency, inspection and adaptation.
It makes transparent your shared understanding of what releasable quality looks like. This makes it easier to deliver releasable Increments Sprint after Sprint. These releasable Increments let you inspect and adapt your work. You can test it with your customers to make sure it’s what they need. And you can build in quality at every step, avoiding costly rework. This gives you a solid foundation for future improvements.
The definition of done vs. acceptance criteria
People sometimes puzzle over the difference between the definition of done and acceptance criteria. That’s because they both help clarify when work is completely completed. But where the definition of done is common to all your work, acceptance criteria are specific to individual pieces of work (user stories or other Product Backlog items). The definition of done tends to cover non-functional factors. In contrast, acceptance criteria cover functionality (and the outcomes this functionality delivers).
You can find out more about the differences between the definition of done and acceptance criteria here.
Definition of done examples
It can be easiest to understand by seeing examples of the definition of done. Since not many of the definition of done examples out there are for non-software projects, we’ll start there.
Definition of done example for a non-software project
If you’re designing a print brochure, your definition of done might include:
|Checked against style guide||𝥀|
|Print-ready PDF created||𝥀|
|Test print approved||𝥀|
|Old brochure digital assets and files replaced||𝥀|
|Brochures sent out||𝥀|
|Out-of-date brochures removed||𝥀|
|Acceptance criteria met||𝥀|
Definition of done example for a software project
For a software project, your definition of done might include:
|Tests written and passing||𝥀|
|Continuous Integration build passing||𝥀|
|Cross-browser testing done on current top 5 browsers according to analytics||𝥀|
|Mobile testing done on current top 3 mobile devices according to analytics||𝥀|
|Google accessibility check passed||𝥀|
|Acceptance criteria met||𝥀|
How to create your definition of done
The best examples are created collaboratively with the whole team: Product Owner, Development Team and Scrum Master. This process builds buy-in and encourages the whole team to be accountable for meeting the definition of done. The discussion helps make sure everyone understands what’s meant by each item on the checklist.
Set aside time at the start of your project to come up with your definition of done. You can do this as part of your project kick-off meeting for example. We’ve found it’s not as fun as some of the other kick-off activities so can suck a bit of energy out of the team. That means you might want to do it separately, maybe in a couple of short iterations.
Make it visible. By posting a physical copy of the definition of done in your workspace, you’re showing that it’s important. And making an electronic copy easy to find makes it more likely the team will refer to it.
But treat it as a living document. Come back to it at regular intervals to keep it relevant and top of mind.
What makes a good definition of done
As noted, a good definition of done is a visible, collaborative, living document. On top of that, it’s also:
- clear — write it in plain language so everyone understands and there’s no ambiguity
- testable — a key way to make it clear is to ensure that it’s a black and white decision whether each item in the checklist has been met
- concise — if everyone can remember each item, they’re more likely to tick them off
- realistic — document what you’re actually going to do, not your aspirations.
How you make sure the definition of done is followed
It’s not easy, and we’ve seen plenty of teams who’ve let it slip.
Start by making sure the Development Team keeps the definition of done in mind when estimating the size of each story and forecasting the stories you’ll commit to. That means they’re less likely to skip items on checklist due to time pressure.
Everyone in the Scrum Team can check that it’s being followed. For example, the Product Owner can check when accepting stories, the Scrum Master at daily stand-up and the Development Team during code reviews. If no-one has mentioned the definition of done in a while, it’s probably getting overlooked.
If you start to find it is getting overlooked, that’s a good sign it’s time to revisit the document. What items are getting skipped and why? Does everyone still understand what’s involved? Is it all still relevant?
By keeping on top of the definition of done like this, you keep adding to the value you deliver your customers. And you make sure your product is the kind of quality you can be proud of.