Definition of Ready
The practice of the Definition of Ready is just as popular as the Definition of Done … However, it must be handled with great care.
Definition of Ready
The Definition of Ready represents the set of criteria that define when a user story (or other items) is ready to be developed. This is often referred to as the “DoR” in Scrum teams.
Scrumbut to Avoid on the Definition of Ready
Be cautious! Avoid making this common mistake: when we refer to “ready,” it doesn’t mean “to-do.” The “to-do” column is typically used to list all the items that the team aims to achieve during the sprint. However, it’s not forbidden to include items that are not “ready” in the “to-do” column; not all items in “to-do” need to be completed when the team selects them.
If needed, you can optionally add a “ready” column for better visibility, like this:
Here’s a refresher from the Scrum Guide on the definition of sprint planning, reminding us that items selected during this ceremony are not necessarily “ready”:
The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint GoalScrum Guide
How to Define Your Definition of Ready?
We can ask developers to provide their requirements for the definition of a “READY” user story. The Product Owner acts as a consultant and can contribute valuable ideas.
Here are some commonly considered criteria:
The User Story Must Be INVEST
“Independent,” “Negotiable,” “Valuable to the user or customer,” “Estimable,” “Small,” and “Testable” – these are the INVEST criteria for user stories. Learn more about it in this article: How to Split User Stories?
Personally, I believe that all user stories should be INVEST by default for quality reasons. However, it’s important that developers agree with this idea (or even the Product Owner).
Set Up Acceptance Tests
Define the tests that will validate the user story’s completeness.
User Stories in Hypothesis and Measurement Mode
These three sentences enable a Lean Startup approach, helping developers understand the foundation of the user stories:
"We believe that ... We will be right if ... What we did .... "
It’s important to note that this addition requires effort from the Product Owner, as it involves more work. However, if the Product Owner invests in this work, it will help share the project vision or project evolution more effectively.
Here’s a concrete example:
"We believe that the mobile phone has become essential to sell some products We will be right if 30% of our customers want to buy our products using their mobile phone What we did: worked on a web app to fulfill the request "
You could create a “Hypothesis and Measure” for Epics, personas, and individual user stories. The key is to associate each user story with one of the defined hypotheses and measurements.
Conclusion
The Definition of Ready, while not a Scrum requirement, is a useful practice to enhance team organization during a sprint. However, remember that an item can become “ready” during the sprint, and it’s not prohibited for all items to be “ready” to enter the sprint backlog.
Be the first to comment