What Product Backlog Refinement is & How to Do it With the Scrum Team

No, the Product Backlog Refinement (PBR) is not yet another new unhelpful meeting imposed by the Scrum framework, quite the contrary.

It may not be officially listed in the Scrum guide, but it is becoming more and more important Scrum Event in agile teams, in order to calmly approach the planning of the upcoming sprint.

What is the backlog refinement, and how does it work? We also give you some tips on how to groom your backlog effectively.

To fully understand the backlog refinement, there is first a need to understand and to be clear on the concept of the backlog.

The product backlog is a list of business requirements for a product or project, translated into user stories that describe the user's needs precisely. It is created and managed by the Product Owner, and the entire team consults it during the sprint planning phase to select the stories and features that it will develop during the sprint.

Backlog refinement, or backlog grooming, is the action of refining the backlog at a dedicated meeting during the sprint.

In concrete terms, refining the backlog is a tactic that consists of:

• clarifying the understanding of the user stories,
• estimating (or re-estimating) the effort required to complete them,
• determining the functional value of each US (user stories) to facilitate the prioritization work,
• removing US (if needed),
• adding US (if needed).

What is the difference between the backlog refinement meeting and the sprint planning?

The sprint planning takes place on the first day of the sprint and aims to define the objective of the sprint and to select the user stories that the team commits to delivering at the end. Like all Scrum events (including the sprint review, the daily scrum…), it is time-boxed and can last up to about 2 hours per week of the sprint.

The backlog refinement is an intermediate and complimentary meeting to the sprint planning. There can be several of them during the sprint, and their purpose is to prepare the ground for the sprint planning, which should be more efficient.

Who should attend this meeting? All members of the Scrum team must participate:

• the Product Owner,
• the Scrum Master,
• the team of software developers,
• other people can participate if they do want to help.

👉 All kinds of relevant stakeholders can be added to the group to discuss which backlog items should be kept or prioritized and why. They could also detail estimates and order the items in the most efficient way.

Refining your backlog on a regular basis has many advantages such as:

• bringing serenity in the planning and the development of the next sprint,
• refining the understanding of the needs,
• preparing the estimation of the user stories,
• allowing for a mid-term review,
• shortening the duration of the sprint planning.

It depends on the efficiency of your team, but you can count at least one one-hour-long backlog refinement meeting per sprint.

However, in a logic of permanent agility, it is advisable to hold several meetings, even if it means shortening their duration. This allows the Product Owner to anticipate and to have time to rework their US before the end of the sprint. It improves the focus and quality of the process.

As a reminder, it is the Product Owner who is responsible for translating a user request or need into a user story, in as detailed and clear a manner as possible.

They will therefore present to the rest of the team the US that they have completed, or at least those that are already well advanced.

The aim is to ensure that the members of the development team have a perfect understanding of the requirements and that they have the opportunity to ask questions and discuss these US.

The Product Owner can then modify or enrich them following the questions and discussions that have taken place.

The team can then validate the user story and move on to its estimation.

👉 If it turns out that the development team does not understand the request, the Product Owner will have to take time to rework and clarify their US to present them again during the next session.

The logical continuation of the validation of the US is their estimation by the developers.

Each team has its own methods and tools for estimating them, but in practice, a US is estimated in points of effort rather than in time.

Among the most commonly used methods, it is possible to note:

• planning poker,
• the t-shirt sizing method,
• the bucket system.

It's up to you to determine which one suits your team and your projects best. If it turns out that a user story becomes too complicated to estimate, it is better to subdivide it into different smaller US for better visibility.

Knowing the estimated workload required for a user story will allow the team to start its prioritization work and plan ahead.

On the other hand, other prioritization criteria can be taken into account, especially the functional value, which is essential. That's why it's smart to determine priority levels according to the value/effort ratio:

• Priority 1 (P1): high business value and easy to develop,
• Priority 2 (P2): high business value and difficult to develop
• Priority 3 (P3): low business value and easy to develop
• Priority 4 (P4): low business value and difficult to develop.

Therefore, the team assigns priority levels to the US, while keeping in mind that the main objective is to deliver maximum value as quickly as possible.

💡 Good to know: prioritization can be done on the whole backlog even if user stories are not all complete because the vision is macro-centered.

• 1st tip: as a Product Owner, prepare the presentation of the US in detail by telling the team what you think, what you think they can do, etc. The more enthusiastic and clear you are about the presentation, the more likely it is that you will be able to present the US to the team. The more enthusiastic and clear you are, the more likely you are to get the team to buy into your product vision and validate the US.

• 2nd tip: welcome questions, comments, and negative feedback. You are bound to find something constructive that will enrich your thinking and therefore your US.

• 3rd tip: don't wait until the last moment and until you have completed all your US to carry out the backlog refinement. It is better to regularly present the finished stories during rapid refinement backlogs in order to anticipate whether they need to be worked on, otherwise the next sprint may be jeopardized. Avoid the tunnel effect!

What about you? Do you think product backlog refinement is of help to your organization? Do you have any advice for a Product Owner who is starting out on the backlog refinement journey? Let us know in the comments!