By Nick Butler
Tags: Agile
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 is that:
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.
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.”
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:
Learn how to run an exercise to develop a definition of done.
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.
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:
The example definition of ready below expands on the INVEST criteria by including ways to avoid these potential issues.
Stories are:
Learn when user stories need a definition of ready and get examples.
A definition of done needs to cover three related areas to ensure each piece of work will be releasable:
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.
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.
For a software project, here’s what your DoD might include:
Get more definition of done examples and tips
Find out about the difference between the definition of done and acceptance criteria.
Read about our experiment with a definition of ready.
