Definition of Ready: Why you should have one in your Scrum / Agile team.
I know, in the Scrum Guide there is not such a thing as “Definition of Ready”, the only required definition mentioned is the “Definition of Done”, but…
quoting the Scrum Guide:
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities.
Hence we need to understand what “ready” means for our team and how we can agree that a backlog item is “ready” for selection in a Sprint Planning. Therefore a shared “Definition of Ready” becomes useful. And this is why, even if there is not direct mention of it in the Scrum Guide, many experienced Scrum teams use it and keep it alive.
Let’s take a step back: what does “Ready” mean?
The previous quote from the Scrum Guide states: Product Backlog items usually acquire this degree of transparency after refining activities. I don’t want to go into the details of the Product Backlog refinement process, but it’s worth pull in another quote from the Scrum Guide that briefly describes it:
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.
The key concept here is that we refine items in order to make them “ready”, so when it’s Sprint Planning time we can be sure that we have prioritised items that are “ready” to be worked on and to be moved into the Sprint Backlog. In other words, we want those items to be actionable. Once an item is put into the Sprint Backlog it should not be necessary (ideally) to gather any other information about it. We should already know what the key requirements are and how we can test it.
This seems sensible, right? Why should we have a formal definition for such a basic thing? Well, because a lot of things seem to be obvious until you realise they are not.
Let’s put it this way: if the refinement is the activity of making backlog items actionable, the “Definition of Ready” responsibility is to answer to one simple question: “what do we need to know in order to make this item actionable?”.
Some teams use a nice acronym to define what characteristics any item should meet to be considered “ready”: I.N.V.E.S.T.
Independent (can be developed without dependencies on other items)
Negotiable (not a specific contract for features)
Valuable (delivers value to the user)
Estimable (to a good approximation)
Small (so as to be done within a Sprint)
Testable (in principle, even if there isn’t a test for it yet)
Although I find this an excellent starting point, I think that different teams can have different needs depending on the context and the domain of work, so each one should craft a more specific list (or description) of what’s needed to deem an item “ready”.
Many teams I worked with in the IT industry use a checklist of this kind even before considering an item estimable:
- If it’s a bug, how can we replicate it?
- If it’s a new feature, what’s the desired user journey?
- If it requires new UI, do we have the mockup(s) or they will be designed as part of the Sprint?
- If the new UI will be designed within the Sprint, do we have all the content/UI specifications
- If it’s a change to an existing content/UI, do we have the before and after content/UI specifications?
- How can we test it? Have we defined all the test scenarios?
I believe that a combination of the I.N.V.E.S.T. acronym and a checklist similar to the one above can really make the difference and allow any team to speed up its productivity and multiply the delivered value by eliminating the waste of time generated by the need for chasing down requirements and/or underestimating an item.
Let me know if you use a “Definition of Ready” in your team and what are your thoughts on it.
