How often should we refine the Product Backlog

The Scrum Guide doesn’t consider the Product Backlog Refinement being a Scrum event. But it has its purpose, and we can see benefits when running a refinement session. Before planning the future sprints, we need a good understanding of what we need to do. The refinement activity offers a splendid structure for organizing the backlog into future milestones. 

Why should we refine the Product Backlog

1. The more of an organized backlog we have, the more the objectives are clear and visible for the team

When we work on a feature, we need o to have a very clear objective so that we know what we want to achieve in the end. The low-level details might not be defined yet, but the end goal has to be clear for everyone. But how can we get this level of clarity? If we establish what are the major steps that we’ll help us meet the goal.

A well-refined Product Backlog will help the Product Owner who will have more visibility over the future functionality. With this visibility comes another important aspect: the ease to forecast when future functionality will be delivered. 

Without a forecast, the Product Owner cannot offer stakeholders an approximate date to use the final product. Forecasting is also important because it lets us gradually see the progress by putting together small pieces of functionality until we see the final product. 

But it’s not only the Product Owner who’ll benefit from an ordered and clear Product Backlog. By having the end goal in mind, the developer’s work will be way more qualitative. Because they’ll know in which direction to go, and what decisions to make from a technical point of view. 

2. It’s a collaboration opportunity between the Product Owner and the Developers

Most of the time, the Product Owner will think about a feature from a user and business point of view. But many times, developers’ insights can help them make some decisions regarding the way they organize the backlog. 

These insights can comprise in identifying an area that needs refactoring. Here, the Product Owner can reorganize some of the PBIs, to make room for the re-factorization. 

Besides that, another important aspect is that developers can ask questions regarding some unclear descriptions. The Product Owner might even not be aware of some characteristics. This way, they get help from the developers and sometimes even bring these topics up in discussions with the client. 

It’s fundamental for these discussions to take place before the planning, for the Product Owner to have the answers before the preparation for the next sprint. 

How often should we refine the Product Backlog 

Unlike the other Scrum events, the Product Backlog Refinement is an activity that doesn’t have a frequency or duration established. We should refine the Product Backlog as often we see it necessary for the following to be true:

1. The backlog has the most import items at the top

The items that have the most benefits for the business should appear on top of the backlog. We want this, because the sooner we go to production with certain features, the sooner we’ll see the revenue increasing. 

The Product Owner will order the backlog as he sees fit. He can consider risks, time to market, or technical debt. Based on the data he gathers from the developers, stakeholders, business analysis, research, he’s the one deciding. 

2. The PBIs that are at the top of the backlog have enough details 

The first PBIs to appear in the backlog are the ones with the most details. They are the first ones to go into the sprint. So they will have the context and level of detail needed for the developers to work on them. 

3. The most important PBIs have a size assigned by the developers 

Sizing PBIs allows the Product Owner to make forecasts, so this is an important tool for them. In the refinement sessions, the Product Owner will present the PBI details to the team. If the request is straightforward and has enough information, the developers can then size the PBIs. 

When the information is not clear or complete enough, it’s accepted for the developers not to size, until things get clearer. However, unsized and unclear PBIs should not get into the sprint. If the Product Owner collects the information they need until the planning session starts, the PBI sizing can happen in the Sprint Planning as well. 

I prefer the team to size items in the Backlog Refinement session so that we have time to plan the sprint in the Sprint Planning. But in some rare cases, when a PBI is needed in that sprint and we couldn’t size it in refinement, we put a size to it in the planning session.  

I have a refinement session of one hour scheduled once per week. For us, this is enough time to prepare for the next sprint and understand very well the PBIs. We have to be careful with these sessions, even if it’s an important activity, it shouldn’t take longer than 10% of the sprint capacity. 

Remember that we need just enough details for the team to start the sprint. One of the Scrum values says that communication during the sprint is preferred over piles of documentation. The PBIs are an opportunity for discussion, not a contract. 

What happens when the Product Backlog is messy

Have you ever seen Product Backlogs with over one-year-old PBIs, and packed up with random ideas that may reach out into a sprint at one point? Or maybe you have such a backlog in the present? If these ideas were important, you would have implemented them already. And if you didn’t yet, they will never see the light of day. 

1. Messy Product Backlogs are a waste of time 

Messy Product Backlogs create confusion and frustration. It becomes a distraction for the Product Owner when the backlog becomes a space where we stack ideas that will become forgotten. The backlog should be a clean space we don’t have to reorganize every time we create a new PBI, wondering where should it fit. 

2. There’s no clear direction about what to do next 

The Product Backlog should be a guide. One that tells us what are our milestones for the project and how we get there. That is why keeping the most valuable items at the top is so important. 

When we don’t do this, it will be difficult every planning to go through all the items on the backlog and pick the right ones. And we could even choose the wrong ones, which won’t bring any value at the end of the iteration. 

3. Forecasting is nearly impossible

An ordered backlog helps us visualize what is coming when we make forecasts. I strongly suggest to the Product Owners I work with and help them sometimes organize the PBIs. However, even if having a clean and prioritized Product Backlog is important, we shouldn’t prioritize all the items at once. We should see only the work for the next 2 or 3 sprints well organized. 

If you have a 6 months project, you’ll be sure only about the work you’ll do in the first month. Why’s that? Because you’ll learn new things once you see how the functionality integrates into the bigger picture. And you’ll find out that some features you thought about doing don’t have the same value anymore. 

The Product Backlog should be easy to read and anyone looking at it should understand what’s coming up. It should include only the PBIs that you know you want to see in production. The ones that will bring value and that are addressing an actual need. Other features, the so said nice to have features, will not bring any value if no one needs them. 

What should happen during the refinement 

1. The Product Owner presents the upcoming PBIs 

I advise the Product Owners to come prepared for this session. They need to be prepared to offer a context of what problem are we trying to solve and why. When this is clear, they can explain what developers have to implement. It’s very important to have the acceptance criteria or part of it defined at this point. The entire content of the PBI will generate discussions where new ideas can emerge from. 

2. The Product Owner and Developers try to find any missing pieces

PBIs are an opportunity for having a discussion, and we can update them with new information based on developers’ input. Developers see things from a different angle and the questions they address might bring in new information for the Product Owner to analyze. 

3. The developers size the items and identify dependencies

The Refinement session starts with the Product Owner talking about each PBI one by one. After he finishes presenting the first one, the developers ask questions making sure they understood it. While having this conversation, the team can discover dependencies or information that is missing from the PBI. 

Also, new PBIs can be created during refinement, and PBIs that are too big to fit into a sprint can be split. Once the team feels comfortable with the level of information, they can try to assign some relative sizes to the PBIs. We size the items using T-shirt sizes during refinement to help the Product Owner organize them. We leave the more low-level sizing for the Planning event when we use story points. 

One thing to avoid doing during the refinement session

I’ve seen members in a Scrum team expecting the Product Owner to have all the answers at the refinement. This is an unrealistic expectation and therefore we have these conversations. To discover things that are unclear, and together try to find the answer. So don’t expect the Product Owner to have all the information. Some things have to be discovered by the team.  

I would like to hear about how your refinement sessions go. Please leave a comment below if you want to share some of your tips.