

What is the best project management software? Discover our comparison and choose the solution adapted to your project management methodology and your business.
Where Thought Leaders go for Growth
No, the backlog refinement 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 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 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:
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. It can last 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 sprint planning, which should be more efficient.
Who should attend this meeting? All members of the Scrum team must participate:
👉 The Product Owner is responsible for preparing, organizing, and leading the backlog refinement meeting.
Refining your backlog on a regular basis has many advantages such as:
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 requirement 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:
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.
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:
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-centred.
What about you? Do you have any advice for a Product Owner who is starting out on the backlog refinement journey? Let us know in the comments!