What is Backlog Refinement (or Backlog Grooming) in Scrum?

How do you eat an "elephant"?

Well, that is a great question to create an analogy about product backlog refinement. So, how do you eat an elephant? Yes, one bite at a time. The Product Backlog is our "elephant," and we consume it one bite at a time. And to do that, the Product Backlog Items need to be refined to bite-size.

What is Product Backlog, and what are Product Backlog Items?

The Product Backlog is an ordered list of all known things/requirements needed to create the Product at a given point in time. It creates transparency and evolves as we learn more about the Product. The Product Backlog Items are these needs/requirements typically expressed as Features, User Stories, Spikes, PoCs, Defects, Issues, Bugs, Test Scenarios, Tasks, Activities or any other decomposition which makes them easy to understand, order, and estimate.

What is Product Backlog Refinement

Consider the Scrum Team is to build an eCommerce portal. The Product Owner conveys that the following functionality to be developed is a payment gateway to start buying the products. But what does it mean to build a payment gateway? Do you need to enable credit card payment or payment via net banking? Which credit card to process? What will it need to allow a credit card? Will we store the credit card information of the customers? How will we keep it, and how will we ensure the security of the stored data? And so on.

Too many questions. And to build the proper functionality in the right way, we would want to have a clear understanding/answers to these questions and many more that might arise. Product Backlog Refinement is the Scrum Team's activity to clarify the PBIs to be developed in upcoming sprints. The PBIs which the team thinks can get done within a sprint is considered ready for the next Sprint Planning.

The Product Backlog Items get refined to this state of readiness during Product Backlog Refinement. Typically, during Product Backlog Refinement, the PBIs are further broken down into smaller, more precise chunks of work; they are ordered and also estimated. It is an ongoing process. As a rule of thumb, Product Backlog refinement should not consume more than 10% of the team's capacity. It is not a rule so that the Scrum team may take more than 10% of capacity during the early stage of product development.

Why Product Backlog Refinement Important

• 1Creates common understanding within the Scrum Team of what it means to build product functionality.
• 2It helps the Scrum Team collaborate, establish, and agree when they can consider the PBI delivering needed functionality.
• 3PO can help the developers understand "WHY" a functionality is essential and needs to be part of the upcoming sprint.
• 4Enable transparency through ordered and estimated product backlog.
• 5Enables the developers to clarify doubts/assumptions about a PBI.
• 6It helps the Scrum Team evaluate if there is a dependency or risk associated with a PBI and how to overcome it?
• 7Breaking down PBIs into smaller chunks makes them easy to estimate.
• 8Helps the PO to order/reorder the Product Backlog to optimize the value of the Product.
• 9Keeps the Product Backlog in a healthy state so that the PO can make forecasts w.r.t upcoming releases.
• 10Refined Product Backlog enables reporting progress towards goals.

Complementary Practices for Optimizing Product Backlog Refinement

Prune the Product Tree (Innovation Games - Luke Hohmann): The Product Backlog often grows huge with requirements from all directions and becomes difficult for PO to optimize the value. In his book "Innovation Games," Luke Hohmann has suggested the game "Prune The Product Tree" to bring back the Product Backlog in a healthy, optimized state. The idea is to consider the Product Backlog as a Tree and then shape it to maximize value delivery.

For example, the trunk can represent the core functionality of the Product, while the edge/leaves represent future functionality. Now, the PO and customers/stakeholders/team can shape it up by exploring new possibilities or removing some existing ones that might not add value. Thirty-Five: It is a technique to order PBIs. The PO writes the PBIs on index cards. Then these index cards are shared in pairs with stakeholders. Stakeholders then get asked to divide five across the cards (5-0, 4-1, 3-2) and write it on the back of cards they are holding.

Then the pairs are switched and shared. Again, stakeholders get asked to look at the PBIs in their hands and repeat the process of assigning numbers. The steps get repeated seven times. By the end of the 7th round, the numbers on the back get summed up. The PBI with the highest (35) sum comes at the top, and the lowest (0) gets placed at the bottom.

Common Anti-patterns

• Product Owner does not participate: The PO does not participate in the refinement. Thus, the developers are on their own to make assumptions on building functionality. As a result, they only focus on "how" they would build the functionality without having the clarity of "why" the functionality is to be built or "what" purpose will it solve if built.
• Leads/SMEs do refinement: Product Backlog Refinement is a whole team activity. When refinement is done only by leads/SMEs, it impedes creating a common shared understanding. Since all team members are not available, the commitment is also impacted.
• No Refinement: Often, teams complain of not having enough time and do not refine it. As a result, they have to spend too much time in Sprint Planning to understand the desired outcomes of building a specific functionality. Also, the estimates are hurried upon and do not give useful insights to make the right forecasts.