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: Product Backlog refinement. The glossary has the following description:

Product Backlog refinement: the activity in a Sprint through which the Product Owner and the Development Teams add granularity to the Product Backlog.

Product Backlog refinement is quite a unique concept in relation to the way Scrum is described in the Scrum Guide, because it’s often mistaken for an Event. It is not actually, since it’s described as an activity. The reason for this deviation is because of a clear difference between an Event like Sprint Planning and an activity like Product Backlog refinement, which is that Events have a timebox. Product Backlog refinement is an ongoing process during a Sprint and therefore not specifically timeboxed, nor happening at a specific moment in time with a set cadence. Let’s look at what other information the Scrum Glossary description gives us.

the activity in a Sprint

We already discussed what an activity is in comparison to an event in the previous paragraph. Something that’s important to notice as well in this part of the description is that the activity of Product Backlog refinement takes place in the Sprint. A possible misinterpretation here is that after every Sprint the team should take time to refine the next Sprint. Don’t be mistaken, the idea behind Product Backlog refinement is that the team takes some time in their Sprint besides doing development work to focus on refining work to be done in the near future. This could be directly for the following Sprint or further away.

through which the Product Owner and the Development Teams

Another misconception is that Product Backlog refinement is a Product Owner activity. The Product Owner is indeed accountable for Product Backlog management of which Product Backlog refinement is part of this. However, when looking at the definition of accountability, this does not mean that someone is the sole person performing work to fulfil this accountability. For Product Backlog refinement even more so the Development Team members are needed. The reason why is described in the final part of the description:

add granularity to the Product Backlog.

To add granularity in the context of a Product Backlog means to break up into more smaller detailed items from one bigger item and to break up vague bigger scope descriptions into more detailed smaller scope, more specific ones. A common misconception is that this means that the technical plan on how to build the Product Backlog items should be created during this activity. This is not the case as Sprint Planning is used to create a just-in-time plan in Scrum. This is again, because of the nature of Product Development in which through emergent insights the plan how to build our product evolves continuously and we want to reflect that in the way we plan our work. Product Backlog refinement is used to refine Product Backlog items. Practically this could mean that the Development Team needs to acquire enough information about a requested functionality to estimate if it’s realistically possible to deliver in a Sprint and understand what the customer actually wants it to be. So expect questions like “You said you wanted an action on your website to trigger this marketing popup. Which action do you want your trigger to be, and where should the popup show up in your opinion?” or “Your self-driving car needs to detect objects. What objects, and what should the reaction be to these different objects?”. This conversation is important to have for the Development Team to understand what actually needs to be build, and you can probably determine from the way the questions are phrased that they are often questions asked by the Development Team to the stakeholders. Naturally the Development Team members are the only ones that can determine whether they have the right information in their Product Backlog items to start working on them.

Conclusion
Being an activity, Product Backlog refinement is an oddity after reading through the events in the Scrum Guide. However, it’s definitely not an optional part of Scrum. A Scrum Team needs to take time to talk about and clarify items with customers because they also don’t know exactly what they want immediately, as is the case often. By having the conversation there’s a lot of untouched potential value to be found in the conversation with our customers, don’t let it fly away!

We’re going full steam ahead again after a short break so expect more very soon about the Product Owner.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*