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 figuring out how often and when to do Product Backlog Refinement can have you scratching your head 🤔

Why, you ask? Because unlike Retrospectives or Sprint Planning meetings, which have a clear time and place in the agile process; Backlog Refinement lives apart from, outside, even beyond the sprint cycle – and there isn’t much guidance on how and when to do it

Backlog refinement is the black sheep of agile rituals.

Backlog black sheep (1)

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

To quote the Guide:

“Refinement usually consumes no more than 10% of the capacity of the Development Team”

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

So in this article we’re going to get to the bottom of:

  • Why backlog refinement is a process, not an event
  • What it means to spend 10% of your time on backlog refinement
  • When to refine your backlog
  • How to find your refinement rhythm

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

 

What is Backlog Refinement?


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:

“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done.”

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-backlog-github
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:

  • 🥇 Set the priority level for backlog items
  • 📈 Align backlog items with OKRs or KPIs
  • ⚖️ Ensure backlog items are appropriately sized
  • 📝 Add detail to backlog items


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.


Backlog refinement is a process, not an event


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 Daily Stand-ups… well, they’re 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.


Visiting the backlog regularly to shape items during the Sprint

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

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:

  • ✅ Have team members added new backlog items?
  • 💡 Do I need to add anything to the backlog?
  • 📝 Can I add more detail to any backlog items?

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.
Backlog Bonsais Parabol

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.

How Often Should You Refine Your Backlog: Daily, Weekly, or Once per Sprint?


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:

  1. Daily
  2. Weekly, or 
  3. Once per Sprint

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.

Find refinement rhythm (1)

1. Daily: Build a habit of continuous refinement


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.

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:

Daily refinement sessions enabled us to have far better understanding of the backlog and keep it estimated and detailed.


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

2. Weekly: Keep your finger on the backlog’s pulse


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


3. Once per Sprint: Backlog refinement that fits your Sprint cycle


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 out 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 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

Find your refinement rhythm by being… agile!

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:

I was working with an engineering manager who wanted to get the developers working more closely on architecture and technical issues. The team had been together for a while but were each doing largely individual work. This new manager wanted his team to learn from one another and be greater than the sum of their parts.

To start, he implemented a ‘bug triage’ meeting – the developers would go through tricky bugs he’d picked and try to solve them together or at least understand them. The team was stretched from Poland to the Pacific, so this synchronous call was one of only two hours they spent all together in a given week.


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

Sprint velocity backlog refinement
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:

“If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music which he hears, however measured or far away.”

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.

 

Conclusion

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:

Individual and team refinement (1)

  • Individual backlog refinement: During the course of the sprint, team members should be individually pruning and cleaning up the backlog – adding detail where they have it and keeping up to date with backlog items. Ideally this should happen daily.
  • Team backlog meeting: The team should have defined or ad-hoc times to discuss the backlog together. This is the time to interrogate user stories, estimate effort, and prioritize what will be taken into the next Sprint. This can happen daily, weekly, or at sprint intervals. The most important thing is that you listen to your team and adapt your strategy according to the situation.

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.

See why Retrospectives with Parabol are better

Run a 2-minute retro with a simulated team, no login required

 

Try a Demo - Instant Access

Gareth Davies

Gareth Davies spends his time helping people and organisations around the world communicate better. He's a passionate advocate of remote work and responsible leadership.