Backlog refinement: how to conduct this Scrum meeting for a more efficient sprint?

By Axelle Drack

Published: August 1, 2025

No, the backlog refinement is not yet another unhelpful meeting imposed by the Scrum framework... quite the contrary.

It may not be officially listed as a ceremony in the Scrum Guide, but it is becoming an increasingly important meeting for agile teams, helping them to plan and run the upcoming sprint with greater serenity.

What is backlog refinement, and how does it work? We'll also give you a few tips for effective backlog refinement.

See all software Project Management

What is backlog refinement?

Definition

To fully understand backlog refinement, we first need to be clear about the concept of a backlog.

The backlog is a list of business requirements for a product or project, translated into User stories that precisely describe the user's needs. It is created and managed by the Product Owner, and the entire team consults it during sprint planning to select the stories and functionalities it is committed to developing 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, backlog refinement consists of :

clarifying the understanding of user stories,
estimating (or re-estimating) the effort required to complete them,
determining the functional value of each US to facilitate prioritization,
remove USs (if necessary),
add US (if necessary).

🇫🇷 The French translation of backlog refinement is affinage du backlog.

Backlog refinement vs. sprint planning

What's the difference between a backlog refinement meeting and sprint planning?

Sprint planning takes place on the first day of the sprint, and aims to define the sprint objective and select the User stories that the team is committed to delivering at the end. It can last around 2 hours per sprint week.

Backlog refinement is an intermediate and complementary meeting to sprint planning. There may be several during the sprint, and their purpose is to prepare the ground for sprint planning, which should be more efficient.

Who participates in the backlog refinement?

All members of the Scrum team must participate in this meeting:

the Product Owner,
the Scrum Master,
the development team,
anyone else who can help.

But each person's role doesn't end with his or her presence around the table (or screen, for video teams).

The Product Owner is responsible for preparing, organizing and leading the backlog refinement meeting. He/she provides the product vision and clarifies backlog elements. He/she clarifies business needs, prioritizes PBIs, and answers questions that may block the team's work.

The Scrum Master ensures that the backlog session remains fluid and structured. He/she also ensures that everyone has their say, and that the process follows agile principles. The Scrum Master is like the conductor of the refinement orchestra.

Members of the development team play a key role, as they are the ones who estimate, cut out and ask the questions that drive the project forward. Their technical expertise enables them to anticipate risks and clarify tasks before the next sprint.

Last but not least, you can invite other profiles to join in from time to time: technical experts, UX designers, or even a stakeholder. If their presence can shed light on an unclear point, why deprive yourself?

What are the objectives of backlog refinement?

Regular use of backlog refinement has a number of advantages:

this preparatory work brings serenity to the planning and execution of the next sprint,
refines understanding of requirements,
prepares the estimation of User Stories,
enables a mid-term review,
can shorten the duration of sprint meeting planning.

And that's not all! This agile meeting aligns the entire Scrum team with the priorities of the product backlog. The result: fewer unforeseen events, less rework, and more value delivered in each iteration.

It also plays a key role in continuous improvement. By refining the elements ofthe backlog, we learn to write stories better, break down tasks more finely, and anticipate dependencies.

Finally, refinement reduces grey areas. It enables the development team to ask the Product Owner all the necessary questions, even before the sprint begins.

How long and how often should it be carried out?

It depends on the team, but at least one one-hour backlog refinement meeting per sprint.

With a view to permanent agility, however, it is advisable to hold several, even if this means shortening the duration. This allows the Product Owner to anticipate and have time to rework his or her US before the end of the sprint.

We often speak of devoting around 10% of development time to this. For a two-week sprint, this represents half a day divided into several backlog sessions.

More experienced teams prefer to break refinement down into 30-minute micro-sessions. The result: greater concentration, fewer interminable meetings, and a product backlog that's kept on track.

The key is to find the right rhythm so that the product backlog is always ready for the next sprint. Neither too early (there's no point in preparing backlog elements that will change), nor too late (last-minute refinement is a recipe for chaos!).

What are the prerequisites for the refinement backlog?

It all starts with the Product Owner preparing the product backlog. He or she selects the backlog items to be discussed:

those with the highest priority,
the most unclear,
those with high stakes for the next sprint.

Each User Story must be written according to the INVEST criteria (Independent, Negotiable, Valuable, Estimateable, Small enough, Testable). Otherwise, beware of confusion in the midst of refinement!

The Product Owner can also pre-fill in certain information: acceptance criteria, business needs, or any useful data to facilitate the estimation process.

Finally, the team must be informed in advance. A shared agenda, a few preparatory docs, and a quick reminder in the diary lay the foundations for an effective backlog session.

💡 Good preparation saves time during the meeting... and avoids treading water.

Backlog refinement procedure

1. Presentation and understanding of user stories

As a reminder, the Product Owner is responsible for translating a user request or need into a User Story, in as detailed and clear a way as possible.

He/she will therefore present to the rest of the team the User Stories he/she has completed, or at least those that are already well advanced.

The aim is to ensure that development team members fully understand their needs, and can ask questions and discuss these US. The Product Owner will then be able to modify or enrich them as a result of the questions and discussions that have taken place.

The team can then validate the User Story and move on to estimating it.

👉 If it turns out that the development team doesn't understand the request, the Product Owner will have to take time to rework and clarify the US so as to present it again at the next session.

2. Refining the estimate

The next logical step after validating the US is for the developers to estimate them.

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

The most commonly used methods include :

planning poker,
T-shirt size,
the bucket system.

It's up to you to decide which one best suits your team and your projects. If it turns out that a User story is becoming complicated to estimate, it's best to subdivide it into different, smaller USs to get a clearer picture.

💡 Good to know: we estimate (or re-estimate) the User Stories for the next sprint, or possibly the one after that, but we avoid estimating any further.

3. Prioritizing backlog items

Knowing the estimate of a User Story will enable the team to start prioritizing.

On the other hand, other prioritization criteria may come into play, notably functional value, which is essential. That's why it's ingenious 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.

The team therefore assigns orders of priority to the US, bearing 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 the US are not all complete, as we are on a more macro vision.

Final tips for an effective refinement backlog

Tip 1: As a Product Owner, prepare the presentation of the US in detail, telling the team what you're thinking, what you think it can contribute, etc. The more enthusiastic and clear you are, the more likely it is that the team will buy into your product vision and validate the US. 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.
Tip 2: Welcome questions, remarks and negative feedback. You're bound to find something constructive to add to your thinking, and therefore to your US.
Tip no. 3: Don't wait until the last moment, when you've completed all your USs, to create your refinement backlog. It's better to present completed stories on a regular basis, during rapid refinement backlogs, so as to anticipate whether they need to be worked on, or else jeopardize the next sprint. Avoid the tunnel effect!

Case study in the application of backlog refinement in business

Imagine a development team in a tech startup, in the midst of redesigning its website. The Product Owner has just received a flurry of user feedback: confusing navigation, slowness on mobile, lack of accessibility.

Rather than throw all these backlog items into the sprint planning fray, the team organizes a dedicated backlog session.

During the refinement backlog, each User Story is dissected:

"Improve mobile loading time",
"Add a keyboard-accessible menu",
"Review the home page tree structure".

The developers ask questions, the UX designers suggest solutions, the Product Owner clarifies the objectives and reformulates certain needs. Together, they estimate the complexity of the requirements and reorganize the list according to business value.

The result: a clear product backlog, well-calibrated PBIs, and a smooth launch of the next sprint. Better still, the Scrum team has gained in cohesion... and serenity.