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

By Axelle Drack

Published: 1 August 2025

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

It may not officially appear in the list of ceremonies in the Scrum guide, but it is increasingly becoming an important meeting for agile teams, helping them to tackle the planning and progress of the upcoming sprint with greater serenity.

What is the refinement backlog 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 describe the exact user need. It is compiled and managed by the Product Owner, and the whole team consults it during sprint planning to select the stories and functionalities that they are 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 practical terms, refining the backlog involves :

Clarifying the understanding of the user stories,
Estimating (or re-estimating) the effort required to complete them,
Determining the functional value of each US to facilitate prioritisation,
removing USs (if necessary),
add US (if necessary).

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

Backlog refinement vs sprint planning

What is the difference between the 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.

The refinement backlog 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 effective.

Who are the participants in the refinement backlog?

All members of the Scrum team must take part in this meeting:

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

But the role of each person does not end with their presence around the table (or the screen, for video teams).

The Product Owner is responsible for preparing, organising and leading the backlog refinement meeting. He/she provides the vision of the product and clarifies the elements of the backlog. He/she specifies the business requirements, prioritises the PBIs and answers any 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. In a way, the Scrum Master is the refinement orchestra conductor.

The 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 risks to be anticipated and tasks to be clarified before the next sprint.

Finally, other profiles can be invited from time to time, such as a technical expert, a UX designer or even a stakeholder. If their presence helps to clarify 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 provides peace of mind when it comes to planning and running the next sprint,
refines the understanding of the requirement
prepares the estimation of User Stories
Allows you to take stock halfway through the sprint,
can shorten the duration of the 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 how 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 backlog refinement meeting of one hour per sprint.

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

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

The most experienced teams prefer to divide refinement into 30-minute micro-sessions. The result: more concentration, fewer interminable meetings, and a product backlog that's kept up to date.

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 an open door to chaos!).

What are the steps involved in 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
those that are unclear
those with a high stakes for the next sprint.

Each User Story must be written according to the INVEST criteria (Independent, Negotiable, Valuable, Estimateable, Sufficiently small, 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 make the estimation process smoother.

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

💡 Good preparation saves time during the meeting... and avoids stalling.

How the backlog refinement works

1. Presentation and understanding of user stories

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 way as possible.

He/she will therefore present to the rest of the team the User Stories that he/she has 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 requirement, and that they can ask questions and discuss these SDUs. The Product Owner can then modify or add to them following 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 does not understand the request, the Product Owner will have to take time to rework and clarify his/her USs in order to present them again at the next session.

2. Refining the estimate

The next logical step after validating the requirements 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 method best suits your team and your projects. If it turns out that a User story becomes complicated to estimate, it's best to subdivide it into different, smaller US to see things more clearly.

💡 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 further ahead.

3. Prioritising backlog items

Knowing the estimate for a User Story will enable the team to start prioritising.

However, other prioritisation criteria may be taken into account, in particular the functional value, which is essential. That's why it's ingenious to determine levels of priority 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: prioritisation can be done on the whole backlog even if the US are not all complete because we are on a more macro vision.

Final tips for an effective refinement backlog

Tip No. 1: As a Product Owner, prepare the presentation of the Release Units meticulously by explaining to the team your 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 Release Units. 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, comments 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 and until you've finished all your US to create the refinement backlog. It's better to present the finished stories regularly, during rapid refinement backlogs, so that you can anticipate whether they need to be worked on, otherwise the next sprint could be jeopardised. Avoid the tunnel effect!

Case study in the application of backlog refinement in business

Imagine a development team in a tech start-up, in the middle 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 throwing all these backlog items into the sprint planning fray, the team organises a dedicated backlog session.

During the refinement backlog, each User Story is analysed:

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

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 reorganise 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 peace of mind.