Definition of ready and definition of done: What’s the difference?
By Nick Butler
This post explains the difference between the definition of ready and definition of done. It shows how both can help you consistently deliver valuable software. You’ll also get example definitions of ready and done, and learn how to create and use them effectively.
While the post talks about the two definitions as they work in Scrum, they fit with any Agile framework. And although we talk about user stories, these stand for any product backlog item.
The key difference between the definition of ready and definition of done
The key difference between the definition of ready and definition of done is that:
- the definition of ready covers the requirements coming into the sprint
- the definition of done covers the product coming out of the sprint.
So the definition of ready (DoR) applies to your user stories. It makes transparent your team’s shared understanding of what’s needed for a user story to be brought into a sprint.
The definition of done (DoD) applies to your working software. It makes transparent your team’s shared understanding of the quality standards a piece of work needs to reach to be releasable.
Other differences between the definition of ready and definition of done
While a definition of ready is implicit in Scrum, it isn’t a formal artefact. This means that creating a formal DoR is optional. The Scrum Guide puts it like this: “Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities.”
Compare this with the definition of done, which is one of the three formal artefacts of Scrum. The Scrum Guide calls it a commitment. “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”
What the definition of ready and definition of done have in common
As the “definition” part suggests, they’re both about making things clear and transparent. And they share the same ultimate Agile goal: helping you consistently deliver valuable working software.
They are also both best when they are:
- developed together as a team (which builds buy-in and shared understanding)
- customised to your team and context (making them meaningful and useful)
- kept relevant (update them if they don’t meet your current needs)
- clear and concise (so they’re easy to use and remember).
Learn how to run an exercise to develop a definition of done.
Definition of ready in more detail
The definition of ready describes the characteristics of an effective user story. Specifically, it describes stories that will let you deliver valuable software by the end of the sprint.
As noted earlier, it’s optional. You only need a formal DoR if aspects of your user stories are stopping you getting them done. If you’re regularly rolling stories into the next sprint, consider creating a DoR.
But watch for the definition of ready becoming more of a hurdle than a help. You don’t need to spell out every detail of a story before you start. Some details are best sorted by working together on the story during the sprint. You want just enough detail, just in time.
Building your definition of ready on the INVEST criteria
The INVEST criteria are a good starting point. INVEST is a mnemonic that reminds you what kind of stories deliver value every sprint.
Effective user stories are:
For a simple description of each criteria and why it matters, read our intro to the INVEST criteria.
What else might stop you getting stories done? Things like:
- not having content, designs or assets when you need them
- waiting for people outside the team to have input into the story (though ideally your team will be able to complete all stories without outside input)
- not knowing the priority of stories
- not having a shared understanding of the stories, including any underlying risks, constraints or assumptions.
The example definition of ready below expands on the INVEST criteria by including ways to avoid these potential issues.
Example definition of ready
- set up to provide all content, designs and assets
- understood by the whole team, including risks, assumptions or constraints
- shared with any external contributors or reviewers to book in their availability.
Learn when user stories need a definition of ready and get examples.
Definition of done in more detail
A definition of done needs to cover three related areas to ensure each piece of work will be releasable:
- Risk-based wrap up
The work needs to be of a quality you’re happy to put in front of users. Testing, peer review and acceptance checks are standard ways of ensuring this.
The work needs to fit together with the existing product, the previous increment. Your Continuous Integration build needs to pass for example.
Risk-based wrap up
Tie off any loose ends that are likely to trip you up later. If there’s anything you can do that’s a good bet to save work later, do it now. For example, simple documentation often saves you and your team time later. And if you choose not to release the work (if you’ve built it for user testing for example), you need to know that you can safely release it later.
Example definition of done
For a software project, here’s what your DoD might include:
- Tests written and passing
- Security vulnerability scan 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
- Code peer-reviewed
- Documentation updated
- Acceptance criteria met
Get more definition of done examples and tips
Learn more about the definition of ready and definition of done
Find out about the difference between the definition of done and acceptance criteria.
Read about our experiment with a definition of ready.