Scrum at Intergral

Here at Intergral, the development of NerdVision and FusionReactor is based on the Scrum Framework. Our Scrum teams have been working successfully and highly motivated for several years. All members of the Scrum Teams have attended corresponding courses. Some of them hold corresponding certifications from Scrum.org or the Scrum Alliance. As the Scrum Master of the NerdVision team I would like to start with this post to reflect on various topics from the Scrum world - of course subjectively and without the claim to be the authority to interpret ;-)

Some thoughts on the Definition of Ready

- Does it make sense to use a Definition of Ready?

- Why is the Definition of Ready not mentioned in the Scrum Guide?

- What role does the Product Backlog Refinement play?

Let me start with an explanation of the terms:

What is a Definition of Ready?

The Definition of Ready is an agreement between the Product Owner (PO) and the Development Team. It usually specifies the conditions when a Product Backlog Item (PBI) is ready to be included in an upcoming Sprint. One of the objectives is to ensure that the PBI is detailed enough, independent of other PBIs, and not too big (Can it be done in a reasonable amount of time?). In this context, the so-called INVEST criteria are often used as guidelines for achieving good PBIs.

For further information, I recommend looking at the scrum forum and the post from Ian Mitchell.

And what is meant by Product Backlog Refinement?

The term Product Backlog Refinement is explained in the Scrum Guide in contrast to the Definition of Ready:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

So if a Definition of Ready is useful and presumably used by many Scrum teams, why is it not mentioned in the Scrum Guide?

To find an answer to this question, it is worthwhile to take a closer look at the explanations of the Product Backlog Refinement in the Scrum Guide.

There it is described that the PBIs are ordered - according to the degree of clarity or detail. The Product Backlog Refinement is used to edit, refine, and organize the PBIs accordingly. The goal is to have the higher-ranked PBIs "ready" for the next Sprint (Interestingly, this is the only place in the Scrum guide where the word ready appears).

Therefore, whether a PBI is ready to be taken over into the next Sprint is decided in the Product Backlog Refinement. A Definition of Ready can serve as a kind of checklist in this process, helping the development team and the PO to reach a consensus on when a PBI is ready for the next Sprint. In the ideal case, i.e., when a Scrum Team is well established and works well together, such a checklist is not really necessary because the Scrum Team knows when a PBI is "ready."

Conclusion

In summary, it can be said that a Definition of Ready can be quite useful, especially if a Scrum Team is not yet well established. Ultimately, the Scrum Team's communication and cooperation in the Product Backlog Refinement decides when a PBO is "ready." A Definition of Ready can help, but in some cases, it can also be an indication for problems in collaboration and communication. If in doubt, it might be worthwhile to address this in the next retrospective.

‍

‍

‍

‍