The definition of done and acceptance criteria: What’s the difference?
By Nick Butler in Agile on April 17, 2019
We’ve noticed lots of people on various forums around the interwebs asking “what’s the difference between the definition of done and acceptance criteria?” so we thought it would be worth clarifying the distinction.
It’s easy to see why people might be uncertain. The two have lots in common. Crucially, they both help you know when work is completely complete.
So how do they differ?
The key difference between the definition of done and acceptance criteria
The key difference between the definition of done and acceptance criteria is their scope.
The definition of done is common to all your work but acceptance criteria are specific to individual pieces of work. (These individual pieces of work might be user stories or some other way of defining your Product Backlog Items (PBIs). We’ll call them user stories from now on.)
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. It defines what’s needed for an Increment to be releasable.
Acceptance criteria make transparent what needs to happen to complete an individual user story. They specify the boundaries of the story and are used to confirm when it is working as intended.
Other differences between the definition of done and acceptance criteria
The definition of done tends to cover non-functional and quality factors.
Acceptance criteria, on the other hand, spell out the functionality and the outcomes this functionality will deliver for the users.
You can see the difference in these examples.
Example definition of done
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||𝥀|
Example acceptance criteria
Imagine you have this user story for a cinema website: “As Mandy Moviebuff I want to be able to subscribe to the Cinerama newsletter so I can get excited about the upcoming attractions, competitions and offers”. You might have the following acceptance criteria:
- call to action content is displayed to alert users that they can subscribe
- user can subscribe by supplying their email address
- user’s details are stored in a database
- spam protection is in place
- user gets a thank you message telling them they’ve subscribed successfully
How and when you come up with your definition of done and acceptance criteria
The Product Owner and the Development Team typically discuss and agree on the definition of done before the project starts. They make the result visible and, ideally, review it often enough to keep it relevant, effective and top-of-mind.
In contrast, the Product Owner and the Development Team typically discuss and agree on acceptance criteria when they are planning each Sprint or refining the Backlog. They record the results with the user story and update them as they learn more about the work involved.
Checking your definition of done and acceptance criteria
The Product Owner checks that each acceptance criterion has been met when accepting a story. The acceptance criteria guide the Product Owner’s testing.
The Product Owner doesn’t usually test that the work follows the definition of done. The whole team is accountable for making sure it’s followed. However, it’s common for a bit of slippage to develop. The whole Scrum Team can help keep on top of this. The Product Owner can ask if the definition of done has been followed when accepting stories. Likewise, the Development Team can check when, for example, they’re doing code reviews. And the Scrum Master can follow up too, as stories are discussed at daily standup for example.
Definition of done, acceptance criteria and the Scrum Guide
One reason people might be unsure about the difference between the definition of done and acceptance criteria is that the definition of done is defined in the Scrum Guide, whereas acceptance criteria aren’t. Acceptance criteria are commonly used with user stories, which are just one way you can specify the PBIs of Scrum.
What the definition of done and acceptance criteria have in common
They both work best when they are:
- agreed as a team
- updated as new learnings come to light
And the Development Team needs to keep both of them in mind when estimating the size of each story and forecasting the stories you’ll commit to.
While acceptance criteria are not an explicit part of Scrum, they fit very well with the definition of done.
Together, they help ensure you deliver a product with functionality your customers are in need of, at a quality you can be proud of.