The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.
Today we are going to talk about one of these terms in the Scrum Glossary: Ready. The glossary has the following description:
Ready: a shared understanding by the Product Owner and the Development Team regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.
The term “Ready” is only mentioned once in the Scrum Guide. It’s mentioned in relationship to Product Backlog items being Ready. Personally I think this description gives a better idea on what it means for an item to be Ready but it’s still open to some misinterpretation. Let’s investigate a bit more by dissecting the description.
a shared understanding by the Product Owner and the Development Team
Ready is a commonly misunderstood and misused term when it comes to its application to Sprint Planning in Scrum. Something I have seen happening is Development Teams using Ready as a stagegate with a set of checkboxes that are obligatory for a Product Owner to check off before they even consider taking the item into their Sprint Backlog. A misinterpretation of the practice Definition of Ready.
As the descriptions tells you, Ready is a shared understanding. By definition this means that both parties are obligated to expend effort to understand each other and it’s not just a one-way activity. In Scrum, this shared understanding requires the Product Owner and Development Team to perform Product Backlog refinement to hold the conversation to both come to a point where Product Backlog items are considered Ready.
regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.
What this conversation is about is described in the rest of the sentence. Ready means there’s clarity of the information needed for the Development Team to know if an item is small enough to be able to be delivered in a single Sprint and if it’s clearly described enough to understand what’s being asked of them to build in the Sprint so they can create a plan on how to do that. This is needed at Sprint Planning because this is the moment in a Sprint where the Development Team decides on which items to pull into their Sprint Backlog. The criteria differ per product and per team, which is why it’s important to at least create transparency on what’s needed by the Development Team to make these decisions.
Often a Product Owner does not have all the answers to their questions, and often Sprint Planning is too late to gather all this information. This is why Product Backlog refinement is always good to do with stakeholders who do hold all the information they might need. A Product Owner should be acting more as the facilitator for this conversation to be held in this context than the provider of answers.
Ready is an often misunderstood term being thrown at the Product Owner by the Development Team as a demand for Product Backlog items to be as detailed and descriptive as possible. This is clearly not the case when reading the Scrum Glossary description which defines it as a shared understanding between the two roles. This means effort from both and work for both.
I sincerely hope the dissection of the terminology in the Scrum Glossary is helping some people to get a better understanding of the framework. If it did, feel free to share your experience, thoughts and criticism in the comments below. I’m really curious!
As the other “R” in the Scrum Glossary, which is “Refinement”, refers back to “Product Backlog refinement” we will be continuing towards the “S” of Scrum.