The practice of the Definition of Ready is just as popular as the Definition of Done … Although the practice is interesting, it must be handled with great care.
Definition of Ready
The definition of Ready represents the set of criteria that define what is a user-story (or other items) ready to be developed. We often call it “Dor” in scrum teams.
Scrumbut to Avoid on the Definition of Ready
Be careful! Don’t make this classic mistake: when we talk about “ready”, it doesn’t mean “todo”. The “todo” is the column generally used to position all the items that we want to achieve during the sprint. However, it’s not forbidden to add items that are not “ready” in the “todo” of our sprint; all items in “todo” have no obligation to be completed when the team chooses them.
You can optionally add a ready column if the scrum team needs it for better visibility like this:
Here is a little refreshment of the Scrum Guide in its definition of the sprint planning, which recalls that the elements 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 Goal
How to define your Definition of Ready?
We will purpose to developers to give their requirements on the definition of a “READY” user story. The product owner is a consultant because he can raise very good ideas.
Here are some ideas of what we can find regularly:
The user story must be INVEST
“Independent”, “Negotiable”, “Business value”, “Estimable”, “Sufficiently small” and “Testable” user story.
I talk about it more precisely in this article: How to split his user-stories?
For my part, I believe that by default all user-stories should be INVEST for quality reasons. However, it’s important that developers agree with this idea (or even the product owner).
Setup acceptance tests
What are the tests that will validate that the user-story is valid?
User-stories in hypothesis and measure mode
These 3 sentences allow you to work in a Lean Startup mode. It is very interesting for developers to understand the basis of the user stories that we will create:
"We believe that ... We will be right if ... What we did .... "
You have to understand, however, that this addition takes time to the product owner because it involves more work; But if the product owner do this work, he will really share the project vision or even the evolution of the project.
Here is a small concrete example:
"We believe that the mobile phone has become essential to sell some products We will be right if 30% of our customers would like to buy our products with their mobile phone What we did: work on a web app to respond to the request "
We could create a “Hypothese and Measure” for Epics, personae, user-stories individually… The first concern is that each user-story is associated with one of the defined Hypothese and Measure.
Conclusion Definition of Ready
The definition of ready which is not a scrum requirement is an interesting practice to improve the organization of the team during a sprint. But be careful! Don’t forget that an item can become “ready” during the sprint and it’s not prohibited that all these items be “ready” to enter the sprint backlog.