It is a working agreement between the team and product owner on what readiness means. It is an input criteria to plan a story in a sprint. It is a way for a product owner to indicate an item in the product backlog as ready to work in sprint. It is the accountability of product owner that there is a definition of ready defined. Scrum team can refuse to take an item into sprint. The team makes explicit and visible the criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming iteration.
Why Definition of Ready is important? Getting started with poorly understood story can create many roadblocks for scrum team. A story without proper information can lead to rework of work at best, or work which takes the completely wrong direction at worst. It’s so clear that a user story has to meet a set of minimum criteria before it’s ready for inclusion in the work of the next sprint. This set of minimum criteria is the Definition of Ready and, like the Definition of Done, should be agreed upon by the Scrum team. This shared definition then allows the team to reject the stories that don’t have clearly defined acceptance criteria. It will save a lot of time if each user story meets Definition of Ready before the Sprint Planning meeting. Definition of Ready Vs. Definition of Done
Many teams use the Definition of Done to check if a user story is finished and the product is ready to be delivered. But what about the user stories that a team receives from their product owner? Teams can check the quality of the user stories using a Definition of Ready. While the value of the Definition of Done (DoD) and Team Working Agreement have long been understood by serious agile teams, in my experience, the Definition of Ready (DoR) is one of the least utilized, yet more powerful tools an agile team can employ. While the DoR can be used for multiple artifacts and activities (Product Backlog, Sprint Review, etc), for new teams I prefer to start with a DoR for backlog item readiness, which introduces the concept into planning preparation, an important part of the work stream.
Definition of Ready for a User Story
User Story defined
User Story dependencies identified
User Story sized by Delivery Team
Scrum Team accepts User Experience artefacts
Performance criteria identified, where appropriate
Person who will accept the User Story is identified
Team has a good idea what it will mean to Demo the User Story
What are the benefits of a properly structured DoR?
Measure a backlog item’s “ready” state
Help the team identify when the product owner or another team member becomes overwhelmed
Keep the team accountable to each other
Reduce pressure on the team to commit to estimates before stories are “Ready”
Reduce “requirements churn" in development
Definition of Ready for a Sprint
The Sprint Backlog is prioritized
The Spring Backlog contains all defects, User Stories and other work that the team is committing to
No hidden work
All team members have calculated their capacity for the Sprint