Over time, various myths and beliefs have surrounded the concept of the Definition of Ready. What does it entail? It’s all about the conditions that must be met for a Product Backlog Item to be considered ready for action and understood enough by the entire Scrum Team so that it can be pulled into the Sprint Backlog during Sprint Planning. While some embrace it enthusiastically, others avoid it like a burning flame. In this article, we aim to dispel any lingering doubts so that you can confidently decide “To use Definition of Ready or not to use.”
What does the Scrum framework say about “readiness”?
First and foremost, let’s delve into the significance of readiness within the realm of Professional Scrum. The question arises: does the Scrum framework place importance on readiness? Let’s find out. In the Scrum Guide, the term “ready” makes a solitary appearance:
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. 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. Attributes often vary with the domain of work.
(Scrum Guide, 2020)
Therefore, we can identify several Scrum elements connected with the concept of readiness:
Product Backlog Artifact: Readiness is closely associated with items within the Product Backlog, known as Product Backlog Items (PBIs)
Done (Definition of Done commitment): Readiness state of PBIs help us ensure that we are making a reasonable forecast for the Sprint. Based on our knowledge we believe we are able to deliver useful, usable and valuable Product Increment during the Sprint.
Sprint event: The readiness of PBIs is essential as it determines their suitability within the time frame defined by the Sprint’s duration.
Sprint Planning Event: Preparing PBIs to attain readiness is a crucial part of the groundwork for Sprint Planning.
Pillar of Transparency: To foster a shared understanding within the Scrum Team, achieving visibility into potential Sprint candidates among the Product Backlog Items is critical. This is an example of embracing Transparency in Scrum.
Product Backlog refinement activity: It’s the process that helps PBIs become ready.
Based on the above description, it can be said that readiness is a characteristic of Product Backlog Items. So, can you use it while speaking about Sprint Backlog or Product Backlog? The question arises: what does it mean “ready Product Backlog”? No major changes allowed? Business analysis is finished based on the initial customer requirements? If so, taking into account that Product Backlog is a living artifact, adding “ready” to that may sound like putting together words that are mutually exclusive. Not to mention the fact that overinvesting in adding details to your Product Backlog may be a waste for you. Changes over time in our Product Backlog are welcome and expected.
The similar situation happens for Sprint Backlog. We are not “ready” with it after the Sprint Planning event; in other words: it’s not written in the stone. It represents a forecast for the Sprint. Sometimes Scrum Teams modify the whole Sprint Backlog when an important learning happens throughout the Sprint that changes the approach how they want to achieve the Sprint Goal.
That debunks the first myth about readiness is Scrum. Readiness is not about the Product Backlog or Sprint Backlog as a whole but about Problem Backlog Items that need to be understood enough and manageable within the Sprint time frame. Still, if you think about it deeper, being “ready” in Scrum never means that we expect PBIs to remain completely unchanged.
Did you notice that there was no mention of Definition of Ready anywhere above? Which leads us to our next myth about it.
Is Definition of Ready obligatory in Scrum?
The answer is short: no (our friend Grumpy Cat is bursting with pride). If the Scrum Guide doesn’t mention it, that means it’s not a must-do in Scrum. However, the Guide does use the word “ready,” which hints that paying attention to the readiness of Product Backlog Items (PBIs) is important. Neglecting this can lead to challenges that make a Scrum Team’s life harder.
If something is not a part of the Scrum framework, it could be considered as either complementary practice (Scrum friend) or something that is against Scrum (Scrum foe). The answer to this question of where Definition of Ready belongs is not obvious at all. Let’s explore the topic of Definition of Ready in detail before we uncover the answer to that question.
WHY of Definition of Ready
Among the various reasons why people begin using the Definition of Ready (DoR), let’s focus on these three key aspects:
Enhancing Learning Opportunities: In a complex environment, making reasonable Sprint forecasts can be challenging. Without creating done Product Increment, feedback loops remain open, and valuable learning opportunities are missed. Using DoR can help maximize the likelihood of learning.
Efficient Sprint Planning: Conversations about Product Backlog Items (PBIs) can spark numerous questions and the need for further exploration. Investing in Product Backlog refinement and ensuring PBIs are ready in advance allows ample time for preparation, making Sprint Planning more efficient.
Motivated and Focused Teams: Prolonged Sprint Planning meetings can be draining and demotivating for teams. Utilizing DoR during Backlog Refinement activities can help reduce the need for excessively long Sprint Planning events and keep the team motivated and focused on the main goal of the event.
Therefore, one may say that our intention is to help ourselves create useful, usable Product Increments, and avoid the agony of long, tiring meetings.
WHAT of Definition of Ready
Typically, the Definition of Ready is a set of criteria or conditions that a PBI must meet to be considered ready to be pulled into the Sprint Backlog, for instance:
Product Backlog Item is INVEST
Acceptance criteria defined
Estimated (when the team is using estimation techniques)
Not bigger than
External dependencies identified and resolved if possible
Another valuable technique to consider is the use of challenging questions, e.g.:
What are the potential risks involved?
Where do ambiguities exist?
What are our constraints?
What assumptions are we making, and which ones carry the most risk?
Creating a Definition of Ready is not a one-size-fits-all endeavor; it depends on your unique context and your team’s specific needs. The key is to tailor it to your circumstances, ensuring that it adds real value.
HOW of Definition of Ready
The Definition of Ready should serve the Scrum Team and assist them during Backlog Refinement. Therefore, it should be collaboratively created by the team. The team needs to determine what constitutes a ‘reasonable level of readiness’ to avoid both overly vague Product Backlog Items (PBIs) and excessive investment in the Refinement process.
If you’re seeking inspiration, try asking the question, ‘What does a ready Product Backlog Item look like to you?’ Use facilitation techniques like 1:2:4:All to delve into the topic and later identify similarities and differences. It can also be valuable to order the listed attributes of ‘ready PBIs,’ from the most important to the least important (e.g., using White Elephant).
Like any practice or concept, the Definition of Ready should be a subject to regular inspection and adaptation.
Is It a Friend or a Foe?
One may find conflicting answers to this question. In general, the most universal piece of advice is: be careful. Need an explanation?
Close your eyes and imagine a muscular, intimidating person standing at the entrance to the club and checking whether you are allowed to come into the club or not. Now, open your eyes, take a look at your Definition of Ready, and find at least 10 differences between your DoR and the person protecting the club. If you failed to find the differences, I would say that you are in trouble 😀
Ok, let’s become more serious. I’ve seen a lot of examples where the Scrum Team that was at the very beginning of their journey with Scrum, benefited a lot from the ideas like Definition of Ready. However I have also faced situations where DoR looked like a muscular person protecting the club. The result of this protection was a very unhappy customer and in general we want to avoid that.
What are the warning signs when you use Definition of Ready?
Paralysis during Sprint Planning, postponing start of the work on some of the items mainly because the DoR checklist is not strictly followed.
Blaming games and upholding silos.
DoR owned by Product Owner or Analyst only.
Paying too much attention to following Definition of Ready, too little attention to Definition of Done and creating Done Increments.
Reduced flexibility and slower response to change; once ready no changes allowed.
Finally, it’s time to reveal the answer. Is DoR a friend or a foe? It depends (Grumpy Cat was expecting a different answer…). There are definitely risks involved and I tend to ask “what kind of problems are you trying to solve using your Definition of Ready?” Maybe they can be addressed in different ways (maybe not, you have to figure it out).
Personally, I am not a fan of the DoR name because “Definition of…” sounds like a commitment, while DoR is just a supporting complementary practice. I prefer to call it “Refinement discussion points or questions” to avoid confusion with Definition of Done which is an important and obligatory element of the Scrum framework.
Summary
We discussed deeply different aspects related to the concept of “readiness” in Scrum and debunked the myths around the topic. We introduced why, what and how standing behind the Definition of Ready complementary practice. While using DoR is not explicitly prohibited in the Scrum Guide, you should be careful because Definition of Ready can be weaponized and it can become a threat to your Agility. You are responsible for your Agile and Scrum journey. Decide together with your team what will bring value to you.
If you are struggling to manage your Product Backlog, you can book a new Professional Scrum Product Backlog Management Skills class or contact us for help with a free consultation.