5 Strategies for Product Backlog refinement

Content By scrum .org

Scrum Teams do it all the time. It happens in Sprint Review, after Daily Scrum, in Sprint Planning, and as part of development. They discuss the upcoming work to gain a shared understanding. This discussion includes:

  • clarifying the deliverables resulting from the work 
  • breaking down the work so that the individual pieces still provide value when completed
  • ordering the work in the Product Backlog so that the goals of the Scrum Team and the organization are best achieved
  • adding new work to the Product Backlog that needs to be done to the product and remove redundant work
  • eliminating dependencies within the work
  • estimating the work in size and value
  • understanding the assumptions in the work

So, it’s all about the future work expressed as Product Backlog items in the Product Backlog. Barry Overeem refers to these items as reminders of conversations that need to happen in the future. Refinement is simply the ongoing activity of having these conversations and thus an essential product management activity.

Why is Product Backlog refinement needed?

In refinement, Product Backlog items are discussed until a shared understanding is reached. Items are broken down until the Developers are fairly confident that they can complete them within a Sprint. This gives the Product Backlog a level of transparency that reduces the risk. The risk is exposed by not completing an item within a Sprint and thus giving away the opportunity to generate value for the organization. That is why refinement is an essential Product Management activity that successful Scrum Teams need to master. 

Scrum Teams know that it is time-efficient to refine only the top items in the Product Backlog because they will inevitably learn new things that change their view of items further down or make them redundant. Therefore Scrum Teams refine only items that move further up the Product Backlog. To avoid refining too much ahead of time, Developers should only spend 10% of their time.

5 Strategies for Product Backlog refinement

Although refinement is an essential Product Management activity, 43% of Scrum Teams do not spend time in the current Sprint to refine work for upcoming Sprints, according to the Scrum Zombie Guide. Five strategies that help Scrum Teams to refine the Product Backlog:

  • Gaining insights 
  • Ordering the Product Backlog
  • Estimating Product Backlog items
  • Breaking down of Product Backlog items
  • Eliminating dependencies

All strategies help Scrum Teams and their stakeholders to have conversations about the upcoming work and thus clarify the items in the Product Backlog.

Gaining insights

A shared understanding of the work is established if the Scrum Team and stakeholders jointly discover insights. Hypothesis Canvas and UX Fishbowl are tools to facilitate this discovery.

Hypothesis Canvas

In product development, more is unknown than known. Customers change their minds, and technologies are changing. Unfortunately, the habit of managing this complexity with fixed predictions and detailed plans still exists in many organizations, even those using Scrum. When Scrum Teams are asked to guess product needs, customer behavior, and product-market fit, they are often doomed to fail. Organizations can change this by empowering Scrum Teams as problem-solving teams, not feature delivery factories.

Successful Scrum Teams don’t start by implementing features. They begin by thinking about the customer’s problems and making assumptions about possible solutions. The Hypothesis Canvas based on Jeff Gothelf’s Lean UX Canvas encourages Scrum Teams to explore problems creatively.

We believe we make progress towards the [product goal] when [users] achieve the [outcome] with [feature].

It helps Scrum Teams and their stakeholders view Product Backlog items not as fixed requirements but as their best guesses about delivering value. Clear success criteria, tell Scrum Teams what outcome the user should achieve using the feature and what impact the usage will have on archiving the product goal. 

In refinement, Scrum Teams work with their stakeholders to develop these hypotheses.

UX Fishbowl

A User Experience (UX) Fishbowl is a Liberating Structure that allows Scrum Teams to explore what the implementation of the Product Backlog item would look like from the stakeholders’ perspective and what it enables for them. 

A UX Fishbowl consists of two groups and two steps, one group being the stakeholders and one being the Scrum Team. The steps are done in a sequence and as many times as needed.

  1. Stakeholders are invited to discuss the questions. “Imagine this feature was already part of the product. How, when, and why would you use it? What steps are involved? What makes it useful to you? What might deter you?” The Scrum Team listens carefully and notes essential insights.
  2. The Scrum Team comes together and formulates follow-up questions based on what they heard. These questions serve as questions for the next round.

This UX Fishbowl opens up opportunities for Scrum Teams to break down large Product Backlog items into smaller ones that are still valuable to stakeholders.

Ordering the Product Backlog 

Product Owners know that ordering the Product Backlog is not something they should do alone. When Scrum Teams order the Product Backlog collaborative with stakeholders, they gain new insights into what can be valuable to the product. Buy a Feature and 20/20 Vision helps Scrum Teams in ordering the Product Backlog.

Buy a Feature  

Scrum Teams involve possible users of Product Backlog items to determine what items are important. Buy a Feature from Innovation Games enables this as follows:

  1. Product Backlog items that can be bought are priced and listed.
  2. Money is divided equally among the stakeholders.
  3. Stakeholders buy Product Backlog items that are most important to them. Each item can only be bought once. Stakeholders can combine their money when purchasing.
  4. When all money is spent, the bought items in the list reflect the collectively important items to the stakeholders. 

To encourage stakeholders to collaborate, the price of some items should be high enough that no one stakeholder can buy them alone. With the total amount of money, it should only be possible to buy half the items. 

20/20 Vision 

Having 20/20 vision means seeing perfectly without having to wear glasses or contact lenses. Scrum Teams can use the following steps to see the order of the Product Backlog perfectly through the eyes of their stakeholders: 

  1. Each item of the Product Backlog is a separate card.
  2. Cards are shuffled and a face-down pile is formed.
  3. The top card is used as a reference and is placed upside down next to the pile.
  4. After revealing the next card, stakeholders decide whether it is more or less important to them and place it above or below the reference card accordingly.
  5. The process of grouping the remaining cards into the new list is repeated until the last card in the pile. A 20/20 vision of the order of the Product Backlog is created, which shows what is important to stakeholders. 

Estimating Product Backlog items

The goal of estimation is to gain a shared understanding of the work in the Product Backlog, not absolute certainty about the implementation effort involved. Scrum Teams estimate Product Backlog items by having developers assign a size to them. The size does not express the absolute size of the Product Backlog item but the size in relation to the other items. Scrum Teams use relative sizes because people can determine relations more easily. 

Magic Estimation and Planning Poker are estimation practices based on relative sizing.

Magic Estimation

Magic Estimation enables Scrum Teams to estimate a Product Backlog in such a short time that it seems like magic. The following steps are required:

  1. The numbers 1,2,3,5,8,13,21,? of the Fibonacci series up to 21, supplemented by a question mark, form possible size values.
  2. A Product Backlog item is jointly assigned a size and serves as a reference for the assignment of the remaining items. 
  3. The remaining Product Backlog items are distributed among the developers.
  4. The developers assign a size to each of their Product Backlog items in relation to the reference entry. If they do not understand an item, the question mark is assigned. The assignment process is done in silence.
  5. After all Product Backlog items have been assigned, the developers inspect the assignments done by others. A new size will be assigned if they disagree with the current size of the item.
  6. If no unique size can be assigned to a Product Backlog item, a size between the two values is assigned to it. If a question mark has been assigned to an item, further clarification with the Product Owner’s involvement is needed until a unique size can be assigned.

The result is an estimated Product Backlog in relation to a reference item.

Planning Poker 

Planning Poker, which goes back to James Grenning, helps Scrum teams understand Product Backlog items and gain a shared understanding of their size. The model for this estimation technique is a poker game. The procedure is as follows:

  1. The Product Owner explains the Product Backlog item to be estimated.
  2. Each Developer individually estimates the item by assigning it a size. All choices remain hidden until everyone has estimated the item. Then, Developers compare their choice.
  3. If there is no agreement on the size, the Developers engage in a conversation over differences and re-estimated again (step 2). This cycle is repeated until an agreement is reached. This agreement reflects the shared understanding of the Product Backlog item.

Possible values for sizing include fingers, gummy bears, or T-shirt sizes.

Breaking down Product Backlog items

Scrum Teams break down Product Backlog items so that the implementation of each item is immediately usable. This vertical breakdown ensures value to the user. Horizontal breakdowns of Product Backlog items only occur in Sprint Planning when a plan for the upcoming Sprint is created.

Break down Product Backlog items by workflow steps

If Product Backlog items contain a workflow, they can be broken down into individual steps. The item that describes that a customer can pay for the goods in their shopping cart can be broken down into the following items:

  • As a customer, I can log in with my account.
  • As a customer, I can pay for my order.
  • As a customer, I receive a confirmation email with my order.

Break down Product Backlog items by happy and unhappy paths

Functionality often includes a happy path and an unhappy path. The happy path describes how the functionality will behave if everything goes as desired. If there are deviations, exceptions, or other problems, unhappy paths are invoked.

The Product Backlog item, which describes that the customer can log in with his account, can thus be further split into two parts. 

  • As a customer, I can log in with my account. This describes the happy path. 
  • As a customer, I can reset my password if the login fails. This describes the unhappy path.

Further breakdown strategies can be found here.

Eliminating dependencies

Although Scrum Teams are cross-functional, they work in a complex environment. This could lead to unforeseen dependencies. Dependencies may hinder the Product Owner from ordering the Product Backlog so that the value is maximized. Dependencies increase the risk of delays and hinder the Scrum Team from creating a usable increment until the end of the sprint.

There are a variety of dependencies:

  • Internal dependencies: Product Backlog items depend on each other. For example, when workflow steps build on each other, when certain Product Backlog items must be part of a release, or when Product Backlog items cohesively deliver greater value.
  • External dependencies: Product Backlog items depend on external factors. Items may depend on business processes such as release processes or purchasing processes. They may depend on third-party systems. The work requires technical changes in an area of the system that is outside the Scrum Team’s control. Completion of an item may need expertise or the support of someone with specific knowledge.

Scrum Teams make dependencies visible in the Product Backlog so they can be eliminated early. Possible steps to make dependencies visible:

  1. Identify the dependencies in the Product Backlog.
  2. Highlight dependencies with arrows to clarify how the items depend on each other or on external factors. 
  3. Create a graph using all items as nodes and with the dependencies arrows as edges. 

The resulting graph provides insights that enable the Scrum Team to eliminate dependencies. Elimination may involve breaking down Product Backlog items, re-ordering the Backlog, finding new technical solutions that do not require an external system, collaborate with other teams in advance, or acquiring missing knowledge within the team.

Product Backlog refinement is essential

Gaining insights in the upcoming work, ordering it in the Product Backlog, estimating it, breaking it down, and eliminating existing dependencies helps Scrum Teams and their stakeholders refine the work to establish a shared understanding. In Scrum, this product management activity is called Product Backlog refinement. It is essential because it reduces the risk of not completing the Sprints work.

Want to learn more?

Hopefully, this article was useful for you. Refinement is one of the many interesting topics that is covered in the Professional Scrum Master course. If you’d like to experience the Professional Scrum Master course, check out my class schedule page for more information.

Leave a Reply

Your email address will not be published. Required fields are marked *