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 a sprint. It is the accountability of product owner that there is a definition of ready defined. The scrum team can refuse to take an item into a 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.

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 has 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 artifacts
• Performance criteria identified, where appropriate
• The person who will accept the User Story is identified
• The 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
• Full-time on project = X hours per day
• All User Stories meet Definition of Ready

Why is Definition of Ready important?

Getting started with the poorly understood story can create many roadblocks for the 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.