Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

By seeing the title Many Agile Practitioners will already starting bombarding with comments saying that the term “Definition of Ready” isn’t described in the Scrum Guide and same as user stories and the Acceptance Criteria embedded in it. Perhaps, you may consider the Definition of Ready is an integral part of the backlog refinement activity, instead of using the Definition of Ready as a sequential and phase-gate checklist. Backlog refinement is an ongoing process, therefore it’s not restricted to an event but considered an activity.

You would have witnessed multiple situations where despite the team’s best efforts, diligence and meeting quality goals (Definition of Done) the customer is disappointed with the results of your teams work. Do you know the Reason ? It is very likely that the refinement process din’t work as well as it should.

In this Agile world, from time to time, end users will have ideas or concepts for a new feature. The concept will be expressed as one or more feature items, and get added to a product backlog by the product owner. The team, working together, will figure out how to turn this concept, expressed as one or more epics and subsequently refined them into smaller and clearer user stories as a real product feature to be included in the next sprint for implementation.

The product owner could work together with the team to define an artifact called “Definition of Ready (DoR) ” for ensuring that items at the top of the backlog are ready to be moved into a sprint so that the development team can confidently commit and complete them by the end of a sprint.

As you know the quality of PBIs has a direct impact on the productivity of the development team – positively as well as negatively. The DoR is kind of the “DoD for the Product Owner”. It helps the PO to know what to do to a user story before he/she can hand it to the Development Team in the next sprint planning meeting.

“If the development team does not have a clear understanding of the Product Backlog Items (PBI), the development effort and time tend to increase significantly, which in turn causes the Sprint to miss its Sprint Goal or not deliver what stakeholders expect.

The Definition of Ready is an important part of the agreements that a Scrum Team develops at the beginning of the work. Different teams will have different Dentition of Ready, and some require less. i.e., some teams just describe the value to the user, prioritize, and write how to demo. Other estimates and communication are in the sprint planning meeting and etc.  

The concept of  Definition of Ready (DoR)  is not quite as common as the Definition of Done (DoD). The DoR defines when a product backlog item (e.g. user story) has been worked out to the extent that it “may” be included in the sprint. The DoR is intended to ensure that product backlog items are sufficiently prepared for the sprint and that the workflow does not have to be constantly interrupted during development because things are unclear that the team cannot clarify itself.

How is the Definition of Ready used? 

As part of the Product Backlog Refinements, the Scrum Team checks whether the next PBIs are ready. If not, it works out the details.

 The Definition of Ready helps the development team understand what to deliver as a result. Based on this understanding, the development team answers the question of whether they can deliver the result. A Product Backlog is “Ready” when it has enough Product Backlog Items at the top that meet these criteria.

What does a definition of ready look like? The Scrum Guide does not specify anything here. Bill Wake was one of the first to define criteria as a checklist. The INVEST matrix.

• Independent and immediately actionably – Product backlog items are independent of each other in the sprint so that they can be reprioritized and better estimated. In addition, unnecessary planning effort for their implementation is avoided. All prerequisites are resolved before the start of the sprint. The implementers give the feedback that they can start.
• Negotiable – PBIs are negotiable so that the details can be discussed and better or cheaper options can be identified.
• Valuable – PBIs bring added value to the customer so that only requirements that add value are implemented and only what is needed is implemented. Backlog items that are not finished provide no value.
• Estimable – PBIs are estimable. In this way, it is recognized whether the implementers understand the backlog item professionally and technically.
• Small – PBIs are the right size to be implemented in one iteration.
• Testable – PBIs are testable by the customer. You have acceptance criteria.

Definition of Ready for a user story:

A definition of ready deals with the user story, wherein the user story is ready to be taken into a sprint. It doesn’t need to be “100 % defined” covering all the acceptance criteria. However, it should be “ready enough” only when the team is confident that they can successfully deliver the user story. In other words, “if something is good to begin”.

• Well-defined User story 
• User story acceptance criteria defined
• User story sized by the delivery team
• Scrum team accepts user experience artifacts
• Performance criteria identified
• The Person who will accept the user story is identified
• A Team is able to ‘demo’ the user story.

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
• Fulltime on project = X hours per day
• All User Stories meet Definition of Ready

Advantages of Definition of Ready:

• 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 helps in minimizing the Rework on a user story.

Sample Definition of Ready (DoR)

• PO and Dev Team need to have talked about the story at least once.
• User Story is clear.
• User Story is testable.
• User Story is feasible.
• User Story defined.
• User Story Acceptance Criteria defined.
• User Story dependencies identified.
• The story must be broken down enough to fit in a single sprint.
• User Story sized by Development Team.
• Scrum Team accepts User Experience artifacts.
• Performance criteria identified, where appropriate.
• Scalability criteria identified, where appropriate.
• Security criteria identified, where appropriate.
• A person who will accept the User Story is identified.
• Team has a good idea of what it will mean to Demo the User Story.

The Product Owners can use Definition of Ready as a guide when preparing for user stories for upcoming sprints. For a team, it is used as a checklist to make sure that there is an increased chance of success in delivering the completed user story, and that there are enough thoughts involved in building the user story before they start to deliver it. So finally, Definition of Ready brings back the focus to backlog grooming meetings and lookahead planning activities. 

Definition of Ready helps in minimising the Rework on a user story.

References: Scrum Events de, Knowledgehut, It-AGile de, Visual-Paradigm, techagilist & AgileIze

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook