Backlog Refinement: When Should it Happen?

Product Backlog refinement (formerly backlog grooming) helps agile teams improve their development process by ensuring the team always has well-defined issues to be tackled in future sprints.

But unlike Sprint Retrospectives or Sprint Planning meetings, which have a clear time and place in the agile process, there isn’t much guidance on how and when to do Backlog Refinement. 

Backlog refinement is the black sheep of agile rituals.

The Scrum Guide says that refinement is an “ongoing process”, but what does that mean in practice?

To quote the Guide:

That provides a loose idea of how much time to spend on it, but how and when you refine your backlog remains a mystery.

So let’s answer the following questions: 

After reading this article you’ll be keeping your backlog more refined than an English croquet-player sipping his afternoon tea ☕

Before we get into answering those questions, let’s go over a quick definition and talk about what we already know when it comes to backlog refinement.

Here is how the Scrum Guide defines product backlog refinement:

The product backlog in its simplest form is a list of improvements to be made to your product.

You can think of the product backlog as a team to-do list of increments of work that need to be completed to move the product forward in a meaningful way.

Parabol’s Product backlog in GitHub. Proposed backlog items are added into the ‘To Prioritize’ column. When they are accepted by the Product Owner, they move to the backlog. Following  Backlog Refinement and Sprint Planning, they are pulled off the ‘Backlog’ column and into the ‘To Do’ column for the next Sprint.

Backlog refinement encompasses a bunch of different activities, including general estimation of effort required to complete a backlog item (t-shirt sizing); adding more detail about requirements as information becomes available; and finally, more precise estimation of effort using planning poker or sprint poker techniques.

The purpose of the backlog refinement process is to:

All of this helps teams arrive at clearly defined and prioritised blocks of work that can be taken forward into the next sprint.

A well-refined backlog makes the Sprint Planning process a lot easier because there are already well-defined items that can be pulled off the backlog to be built.

There’s a common misconception that backlog refinement is another event that can be timeboxed for an hour at the end of the Sprint.

And we get it. Agile is governed by a set of ceremonies or rituals that take place at specific times.

We know that Sprint Planning comes at the start of the Sprint. We know that Retrospectives come at the end of the Sprint. And the Daily Scrum is daily.

It’s natural to want to schedule backlog refinement at the end of the Sprint just like the other rituals.

But if you only look at your backlog once per Sprint it’s going to be a hot mess.

There’s a reason the Scrum Guide talks about backlog refinement as a “continuous process” and tells us that the product backlog is a “living artifact”. Because it needs daily attention.

Ideally, you will be visiting your backlog regularly to check if there’s more detail you can add to specific tickets.

That doesn’t have to be a long process. It might just be a 5-minute scan of the backlog with 2-3 minutes adding some additional detail every day or two.

This daily practice is especially important for the Product Owner, who holds overall responsibility for the backlog. As with all things in agile, reviewing the backlog daily isn’t a strict rule, but a guide.

You can ask yourself the following questions when you visit the backlog:

You’ll want to prioritise thinking about items near the top of the backlog, since they are most likely to be taken forward for the next Sprint.

Estimating the effort of backlog items should always be done during your group discussions, since arriving at an estimate is a negotiation.

You can think of your product backlog like a Japanese Bonsai tree.

It needs daily care and attention. You need to prune and clip at it to make sure it is the right shape and size. You need to nourish it and actively manage it to make sure it is following the correct path of growth.

So before we talk about how often you should meet with your team to discuss the product backlog and do estimation, know that you should be in and out of the backlog on a regular basis, shaping up items for the next Sprint.

Working on the backlog continuously rather than just once per Sprint makes the time we spend together discussing the backlog much more valuable and constructive, because backlog items already include a lot of detail.

That means you can spend your backlog refinement meeting on high-value actions such as estimating effort rather than simply refreshing everyone’s memory about what’s on the backlog.

By the same token, spending 10% of your time on backlog refinement doesn’t mean scheduling one meeting at the end of your Sprint and ignoring your backlog until then.

It means refining the backlog continuously AND meeting to refine together.

It’s important to separate the dynamic act of backlog refinement from all team backlog discussions.

You have a ton of freedom to decide how and when and how you do backlog refinement in your team. For some, that provides much-needed flexibility. For others, it can be positively anxiety-inducing to have no clear rules!

We already know that backlog refinement should happen on an ongoing basis, because it is a “living artifact”.

But how often the team should come together to estimate effort and prioritise the backlog is up for debate.

Here are three guidelines for when and how often to refine the backlog together.

We recommend refining group refinement sessions either:

And to supplement these with additional ad-hoc conversations as needed.

Here’s a useful decision tree to give you some guidance on how often to meet with the team for backlog refinement discussions.

In the spirit of the Scrum Guide, daily sessions build a habit of continuous refinement. It may seem rather daunting to have a backlog refinement session every single day. But it doesn’t have to be.

If you’re already running a Daily Standup, you can pull everyone together to look at the backlog and have a short discussion every day at the end of the Standup about prioritisation and the details of user stories. You can even try the “walking the board” approach to standups.

Daily sessions are a great option for teams that have just begun implementing agile, because it builds the habit of regularly visiting the backlog and pruning it.

Taking the time every day to pull out a ticket and discuss it in more detail means that when it comes around to Sprint Planning, everyone is familiar and up to date with what’s on the backlog.

This helps you to avoid the scenario where the whole backlog refinement meeting is simply people trying to get back up to speed with what each ticket is about.

If a ticket is going to take longer to discuss, it can be pulled out into a Lean Coffee, or rolled over to the next day to discuss in more detail.

One agile practitioner told us that:

Pros:
✅ Builds a habit of refining the backlog
✅ Helps the team remain familiar with backlog items throughout the sprint
✅ Saves time explaining tickets at a single refinement meeting

Cons:
❌ There isn’t always provide enough time to go into detail
❌ Team may get distracted from current sprint goals
❌ Developers may lose respect for the process because it is too frequent

Having a weekly refinement session helps your team to keep their finger on the pulse of the backlog without it becoming overwhelming.

Weekly refinement sessions prevent all backlog discussions being pushed to the end of the sprint where the agile process can be stuffed with meetings, including the Sprint Demo, Sprint Review and Retrospective, which are quickly followed by Sprint Planning.

When you are racing to ship at the end of the Sprint and can see your calendar filled with meetings, it can be pretty stressful.

Doing some of the team refinement and estimation work before the end of the Sprint in a weekly meeting can reduce that anxiety.

In fact, weekly product backlog refinement offers a more sustainable way of engaging with the backlog. It’s (kind of) continuous, but it also allows your team space during the week for uninterrupted focus on current Sprint goals.

Scheduling the backlog refinement session at the end of the week, for example, allows your team to consolidate what they have completed in the week and have clearer views on the items they might want to prioritise on the backlog.

Whereas starting the week with backlog refinement might provide a nice way of easing into that week’s work.

If you’re working in two-week Sprints this process gives you two refinement sessions per Sprint. One mid-Sprint, and one at the end.

Pros:
✅ Semi-continuous way of keeping up with the backlog
✅ Prevents Sprint-end being overloaded with meetings
✅ Allows for a backlog engagement mid-Sprint

Cons:
❌ Developers may feel that it is too often
❌ May still distract from current Sprint goals
❌ Higher risk of spending too much time on the backlog

You can block out a specific time for backlog refinement in a bunch of different ways: during the Sprint Review, prior to Sprint Planning, or even after Sprint Planning.

The structure of Agile methodology is a series of meetings or processes. What happens between those processes is up to you. But the processes give structure to your work.

That’s why it makes sense for many teams to classify product backlog refinement as another Sprint milestone. For one, having a dedicated meeting for refinement is a more familiar way of engaging with tasks.

Unlike daily or weekly refinement sessions, your team knows that attending the refinement meeting at the end of the Sprint is non-negotiable. And since it only happens once per sprint, people are more likely to be focused on the task at hand and respect the process.

Having a dedicated meeting also gives you the time to dive deep on individual tickets, build user stories together and discuss tickets in detail. In principle that all makes sense. A once-per-Sprint meeting can be very powerful if the team have been engaged with the backlog throughout the Sprint.

But sometimes developers do not take a deep look into the backlog until the refinement meeting. Teams can end up using their precious time together trying to remember what the backlog items are and why they were added.

By the time everyone knows what’s what, you have 10 minutes left to add depth to user stories, hold detailed discussions, or estimate effort.

That’s not ideal.

High-functioning agile teams have a lot of shared context and developers are regularly consulting the backlog. Because of this, the team can move through issues more quickly, so refinement doesn’t need to happen as often.

When you’ve built a high Sprint Velocity, a once-per-Sprint refinement session might be the most time effective approach for you.

Pros:
✅ Higher engagement as considered an agile ritual
✅ Allows dedicated time for detailed conversations
✅ Isolates the refinement process so it doesn’t distract from Sprint goals

Cons:
❌ Wastes time talking through basic info on tickets
❌ Potential for the meeting to drag on
❌ Can result in more poorly-defined user stories

Being agile means more than simply following the principles set out in the agile manifesto. It’s about being flexible. It’s about listening to what your team needs. It’s about experimenting and growing together.

While agile is full of different techniques, meetings and processes, you don’t need to follow any of them by the book. That doesn’t make you a bad agile practitioner. It doesn’t mean you’re doing it wrong somehow.

Choosing a way of refining your backlog is about finding what works for your team.

For young teams that are working together for the first time or are new to agile, micro daily refinement meetings might be just what they need to build the habit and shared context to improve Sprint Velocity.

Here’s a great example of how getting together to work on bugs or on the backlog can lead to more shared context and knowledge:

As your team work together more and more, your Sprint Velocity will increase.

When that happens, you can experiment by shifting daily refinement to weekly refinement to lower the burden at the end of the sprint but keep your finger on the pulse.

As you see more improvements in velocity, you can extend your refinement sessions to once per Sprint, when you know that your team are actively visiting the backlog and in the habit of individually adding detail on an ongoing basis.

Bear in mind that even some high-functioning teams may prefer to have some daily micro refinement sessions on an ad-hoc basis. Maybe your official rhythm is once per sprint, but a tricky user story or epic requires more discussion outside your fixed meetings. Why not organise a Lean Coffee or Check-in meeting to make the time?

Just because your refinement meeting takes place once per sprint, for example, doesn’t mean you can’t also have ad-hoc user story sessions once or twice per week. It’s about finding what works for your team.

It’s all about discovering how you work best together. And that may change over time, as teams mature. 

To quote the words of Henry David Thoreau:

Listen to the music of your team. If the beat is fast, roll with it.

If you need to slow down and add in some extra time for discussion.

But always keep your ear to the ground and be ready to adapt.

That’s what being agile is all about.

Agile teams have a lot of freedom to decide how they want to tackle product backlog refinement.

But high-performing teams all understand one thing: backlog refinement is a process and not an isolated event.

Teams that approach backlog refinement solely as an event will struggle to refine their backlog appropriately. There’s a higher risk that user stories are poorly defined, epics are classified as stories, and the backlog is not appropriately prioritised.

That’s why teams should engage in two practices:

Generally, newly formed teams or those adopting agile for the first time, will want to start off adding refinement time to the end of daily stand-ups to build a habit of continuous engagement.

This helps everyone to get familiar with the backlog and accelerates the speed at which the team gets to grips with the code-base. 

As time goes on and Sprint Velocity improves, you may want to make coordinated refinement meetings less frequent – weekly or once per Sprint.

It all depends on how your team is performing and what they need.

Being Agile is all about being flexible. So if you have tricky stories that need more discussion outside the allotted time, make the time for them! 

If you listen to the music of your team, you’ll find your refinement rhythm in no time.