By Nick Butler
Tags: Agile
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.
According to the Scrum Guide, the definition of done is a formal description of your quality standards. Specifically, it’s the quality required for work to become part of the Increment. It ensures members of the Scrum Team have a shared understanding of what it means for work to be complete.
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.
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. On a software project, this might mean your definition of done specifies that your Continuous Integration build is passing for example. 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.
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.
Some teams also have a definition of ready. While the definition of done covers the working software coming out of the Sprint, the definition of ready covers the requirements coming in. Specifically, what do Product Backlog items look like for you to deliver valuable software by the end of the sprint?
Learn more about the definition of done and the definition of ready.
It can be easiest to understand by seeing examples and, since not many of the definition of done examples out there are for non-software projects, we’ll start there.
If you’re designing a print brochure, your definition of done checklist might include:
| Checked against style guide | 𝥀 |
| Readability test passed | 𝥀 |
| Spell-check run | 𝥀 |
| Peer reviewed | 𝥀 |
| Proofread | 𝥀 |
| 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 | 𝥀 |
For a software project, your definition of done checklist might include:
| Tests written and passing | 𝥀 |
| Continuous Integration build passing | 𝥀 |
| Security vulnerability scan 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 | 𝥀 |
| Code peer-reviewed | 𝥀 |
| Documentation updated | 𝥀 |
| Acceptance criteria met | 𝥀 |
Get ideas for your own definition of done by checking out what other teams have come up with.
Eleven real-world definition of done examples (PDF)
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. And 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. However, we’ve found it’s not as fun as some of the other kick-off activities. That means it can suck a bit of energy out of the team. As a result, 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 checklist 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.
To help teams come up with a definition of done that everyone understands and upholds, we’ve put together a step-by-step guide to creating a one as a team.
How to run a definition of done exercise
As noted, a good definition of done is a visible, collaborative, living document. On top of that, it’s also:
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 in Sprint planning. Factor it in 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 the 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’s 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. As a result, you make sure your product is the kind of quality you can be proud of.
