What is Backlog Refinement?

Have you ever held a project planning meeting where nobody knew which tasks to prioritise? A meeting in which nobody wanted to put an estimation on the amount of effort a thing might take to complete? And where no-one had a clear definition of “done”?

If that’s the case, backlog refinement might be just what you need for:

But unlike other agile rituals, such as retrospectives and daily standups, teams have a lot of flexibility on how and when they do backlog refinement.

To help you out, we’re going to cover almost everything you need to know about backlog refinement. So whether you’re a seasoned refiner or a rookie, there’s something here for you.

By the end of this article, you’ll be able to answer the following questions:

Product backlog refinement is the process of shaping and prioritizing items on the product backlog.

Refinement helps teams shape-up well-sized, detailed and discrete pieces of work that can be tackled in future Sprints.

As a rule, your product backlog should be closely aligned to your product roadmap.

The Scrum Guide defines product backlog refinement as follows:

Having an organized and detailed backlog helps teams make more accurate estimations of how long a task will take to complete.

And when estimations are more accurate, it’s easier to plan the correct amount of work for the Sprint and fewer tasks carried over into the next one.

Backlog refinement incorporates several different activities, such as t-shirt sizing, Sprint Poker, and prioritization. But we’ll get into all of those a bit later.

What you need to know now, is that refinement activities are designed to help teams develop a more precise time estimate for shipping items and breaking them down into an easy to follow list of clearly defined tasks.

At its core, backlog refinement is the act of adding more and more detail to backlog items over time using different techniques.

Adding detail helps teams form a better idea of how long a task may take to complete and what resources are needed to complete it.

For people that are new to Agile or the Scrum framework, backlog refinement can pose a few problems.

The Scrum Guide gives a lot of guidance on when the different meetings should take place.

But when it comes to backlog refinement, it’s all on you  

Let’s quickly go over what the Scrum Guide does tell us:

And that’s it…

While refinement may be one of a team’s most important continuous tasks, the guidance on when and how to do it is very limited.

That gives you and your team a lot of freedom to decide:

When to do backlog refinement

How often to hold refinement meetings

What techniques you use to refine the backlog

So let’s move onto who is responsible for defining how you refine your backlog.

You can think of the product backlog as the product roadmap expressed in small increments of work.

Those small increments of work are individual product backlog items.

Since the product backlog is aligned to the product roadmap, the Product Owner holds overall responsibility for the backlog.

That means the Product Owner should lead backlog refinement meetings.

The Product Owner’s duties are:

While the Product Owner is responsible for shaping and nurturing the backlog, the development team is expected to add detail to individual backlog items throughout the Sprint.

The Scrum Master should also attend backlog refinement meetings, either to sit-in or to facilitate discussions.

Managing backlog refinement sessions and the backlog itself should help the Product Owner effectively prioritise items that add customer value, balancing urgent needs and the product roadmap.

Imagine for a second that your team is a super-fast bullet train. Let’s call it the Agile Express 🚆. You’re a high-performance machine with a high sprint velocity. You’re even able to go around corners and tackle some unexpected bumps at speed.

Your conductor already knows where this high-speed train is going because he/she has the trusty product roadmap in hand and has already charted a course.

If the train represents your team blazing ahead, and the product roadmap shows your destination, then each sprint and its associated tasks are the tracks that take you there.

At each Sprint Planning meeting your team lays down an extra two weeks of track that get you closer to your end destination without compromising velocity.

Refined backlog items are a bit like all the pieces of track that are ready to lay down in front of the train to get you to the end destination.

Maybe you have a healthy store of track ready to go and you know you won’t run out. Those pieces of track are the correct size, they’re well-defined and there are no imperfections.

Even as the train moves ahead at high speed, you can lay them down quickly enough to keep the train moving forward at the same velocity.

Now imagine that you haven’t looked at your backlog in weeks or maybe months. The train is moving ahead at speed and the conductor starts panicking. The only track you have is the wrong size, poorly defined, and you don’t know how far it will take you.

The train has to slam on the brakes to make sure it doesn’t go off the rails. Maybe it even comes to a grinding halt, eradicating the velocity built up over time.

The purpose of this analogy is to show that backlog refinement helps your team maintain sprint velocity. It means that even before you get to the Sprint Planning meeting, there are well-defined tasks ready to be moved to the Sprint Backlog.

You want to be in a situation where you have 2-3 sprints-worth of track ready to be laid down at any time.

Backlog refinement is important because it enables you to:

👀 Get greater clarity on priorities: Having a prioritised backlog helps teams focus on what’s important and see further ahead than just one or two Sprints. The backlog also helps teams see how smaller tasks fit into the larger product roadmap.

🏃 Maintain sprint velocity: Refined backlogs show developers exactly how long an item should take to complete and what tasks they need to do to ship that piece of code. Having detailed backlog items that are ready to go helps developers prioritise execution, since all the thinking and planning has already been done. That helps the team maintain a high sprint velocity.

⏳ Run more efficient meetings: Is there anything worse than a meeting that drags on too long? Active backlog refinement throughout the sprint makes the Sprint Planning process short and sweet, since items are already prioritised, sized and detailed.

The Scrum Guide doesn’t give any hard and fast rules, so it’s up to you and your team.

Most teams will choose to refine at least once per sprint using a method like Sprint Poker estimation. Others do it continuously, and check in together once per sprint.

Here are a few things you can do to figure out a way forward for your team:

While refinement is a continuous process, it’s important to have a scheduled time where you sit down together as a team and go through the backlog together.

Refinement meetings could take place:

If you’re not sure how often to schedule a refinement meeting use this handy decision tree or read more about when refinement meetings should take place.

Team refinement meetings offer a dedicated time when you can riff off each other to add additional detail to stories, validate proposals, and do story estimation using t-shirt sizing or Sprint Poker.

Most teams opt for a weekly refinement meeting, but if you’re a young team or working together for less than 3 months, you might want to do it even more often so your team can understand the code base more quickly and build shared context. 

In between scheduled refinement meetings the Product Owner should be shaping and prioritising the backlog every day.

If ad-hoc discussions are needed to further refine a tricky item, the Product Owner should make time for the team.

Developers and engineers should also be adding detail to backlog items as and when new information is available.

Depending on where you maintain your backlog, your daily practice may involve holding discussions about backlog items within Jira or GitHub.

How often you do backlog refinement is up to you and your team.

But creating a habit of daily micro-refinement, helps ensure all team members know what’s on the backlog and add detail when they have it.

In the long run, this good habit will save you a lot of time when you schedule backlog refinement meetings or hold your Sprint Planning meetings because your whole team is already familiar with the items on the backlog and they likely have more detail in them already.

There are oh-so-many techniques you can use to take rough backlog items and polish them into shape.

All of these techniques form part of the backlog funnel. 

The backlog refinement funnel shows the tasks involved in refining items until they are ready to be taken into a future sprint.

As items get closer to the bottom of the funnel they become more refined and accurate.

Items often become smaller as well, as some large backlog items are broken into multiple smaller items that are either more discrete or a more appropriate size. 

Let’s go through a few of the most common refinement activities so you can boost your arsenal of tactics and refine backlog items even better.

Let’s start with the task of adding backlog items.

It may sound simple, but there’s often some confusion about how, when and by whom backlog items can be added.

What’s more, many items, including bugs, ad-hoc ideas or additional feature recommendations can end up on the backlog.

As a developer, you’ll want to get to the bottom of how backlog items are added:

The answer to this question may depend on the following factors:

Generally, the Product Owner will want to keep a handle on what goes into the Product Backlog, since it should be aligned with the Product Roadmap.

Smaller companies often keep everything in one backlog, including bugs.

Other companies keep the product backlog, design backlog and bug backlog separate, to maintain clarity. 

As a rule, Product Owners should clearly explain to their team the process for adding items to the backlog.

Sometimes it will be just fine for developers to add a backlog items independently, other times the Product Owner will request a quick message informing them that a new backlog item has been added and why.

On occasion, a Product Owner will want to have a firm grip on the Product Backlog so they can keep everything on track.

If you’re new to a team, it’s worth consulting with your Product Owner to understand what the process is. 

You’d be forgiven for thinking that backlog refinement was a purely technical process.

But oh how you’d be wrong!

Buckle up, because it’s time to get those creative juices flowing! ‍

User stories are essentially backlog items creatively expressed in customer-focused language.

Every backlog item has a user story that explains why it exists.

And multiple backlog items with user stories sit under an Epic, which is a larger piece of work such as a feature update.

An Epic has been completed when every user story underneath it has been completed.

It may sound confusing, but it’s not so tricky.

When crafting user stories you need to take the time to step outside yourself and into the shoes of a customer and ask “how would this piece of code benefit me as a user”?

Here’s are two examples of the same backlog item. One is phrased as a user story and the other is phrased as an end goal.

The first example is framed in user-focused language which helps the team see the value of what they will build. It shows the precise role the the feature serves and what it enables them to do.

The second example is completely disconnected from the user experience. It doesn’t give the team context for why that development work is important or what it delivers for users.

Writing up user stories may sound like a rather superficial and low-value task at first glance, but they are much more important than we give them credit for.

User stories help your team to:

For example: A story may tell us that our user should be able to easily see what meetings have been held across all their teams in Parabol. So our starting point is figuring out a creative solution to make that a reality, and all options are in play.

When we focus too much on what we need to do, we often limit our options. We are blinded by tasks and minutiae and don’t take time to think creatively about the bigger picture.

👋 Read more: How to Write User Stories

If your backlog items are in good enough shape, you might try out t-shirt sizing with your team.

Don’t worry, nobody has to take their clothes off for this exercise

T-shirt sizing is a simple estimation technique you may use with your team to get an initial flavour of how large or small a project is.

It usually takes place when there is a good amount of detail in a backlog item, but there are still a few unknowns.

At a minimum the scope of the project should be broadly understood.

In practice, the Product Owner will introduce a backlog item and ask members of the development team to state their best estimate of how large or small the item is, using t-shirt sizes.

Everyone should make a choice independently and reveal it at the same time.

This practice helps to ensure that everyone answers honestly and it prevents team members from anchoring their estimates on others.

What emerges is either an iterative discussion or agreement on the size of a project.

This rough estimation method is particularly useful for making sure that items are the right size to enter the Sprint Backlog in the future.

T-shirt sizing gives teams the opportunity to break L or XL projects down into smaller and more manageable parts that are good candidates for the Sprint.

By the same token, t-shirt sizing helps identify backlog items that are actually Epics and should be broken down into multiple backlog items.

T-shirt sizing is usually followed by a process of splitting out backlog items and adding additional detail before more precise estimation using Sprint Poker or using a method like T-shirt Sizing once again.

It may also be the only estimation technique you use in your backlog process.

Let’s say you’ve got to the stage where you’ve written up your user stories, you’ve got plenty of detail in your tickets, and clear acceptance criteria to know when they are complete 🙌

Now it’s time to estimate effort again!

Except this time you’re going to get more precise and reach better story point estimates.

While T-shirt sizing is great for rough estimation of effort, sometimes you need to get a bit more accurate. Using a Sprint Poker or Planning Poker process is a great way to do that.

Sprint Poker usually takes place during your scheduled refinement meeting, when everyone is gathered together, in-person or remotely.  

Typically, the Product Owner will take an item off the backlog and introduce it to the team. After reading through the user story, associated tasks and acceptance criteria, each team member will estimate the effort involved in shipping that item.

They do it by choosing one of the Sprint Poker cards 🃏

The higher the value of the card, the higher the effort.

It’s simple really.

Once again, everyone should vote independently so nobody anchors their estimates against others.

Everyone turns their cards over at the same time for the big reveal.

Ideally, everyone will have chosen a similar number, leading to a quick discussion about how many hours the task will take. This will be promptly documented in the backlog.

But oftentimes people will choose very different numbers. That’s when it gets interesting.

Some people may have additional knowledge about a specific type of problem or the code base that others don’t, which makes this a great opportunity to share information.

Now is the chance to go around the room and ask everyone to explain the reasoning behind their estimate.

After a period of negotiation, the team should arrive at a rough estimate, which can be documented in the backlog. Sharing information and views in this way helps the team arrive at a more accurate estimate that everyone can agree on.

This process helps to appropriately size items and assign them a value in terms of hours of work. Estimation is important because it helps teams make sure they are taking a reasonable amount of work on in each Sprint.

You can run a planning poker session by using cut out cards or by using Parabol’s free Sprint Poker tool that will guide you through every step of the process.

Prioritising the backlog is the prerogative of the Product Owner

But it often falls to all team members to negotiate what needs to be prioritised.

The Scrum Guide claims that the product backlog is a “living artifact”. That means the order of the backlog may change over the course of the Sprint as items begin taking form and detail is added.

Maybe priorities also shift mid-Sprint and items need to be shifted around.

Usually there will be a time during the backlog refinement meeting to discuss the prioritization of the backlog and whether anything needs to be moved.

Saving prioritization activities for the refinement meeting might be the safest way of ensuring everyone is aware of why items have moved up or down the backlog.

If prioritization is not discussed in the backlog refinement meeting, it will be in the Sprint Planning meeting.

During Sprint Planning, the team will take the items at the top of the Product Backlog and move them into the Sprint Backlog to be worked on during the upcoming Sprint.

The backlog has to be well prioritised for this process to take place.

Led by the Product Owner, the team will decide which tasks to take forward based on their priority level and estimated hours they take to complete.

The number of items may vary from sprint to sprint.

The Scrum Guide says that:

Having clear prioritisation and good effort estimates are solid prerequisites for taking items into the next sprint.

Backlog refinement is the high school rebel of agile rituals 

It doesn’t quite fit in anywhere and it’s not bound by any rules.

And despite that, it’s still one of the most crucial parts of the agile process.

In this article we’ve discussed what backlog refinement is, who is responsible for the backlog, why it’s so important, and we’ve gone over some of the main techniques for refining the backlog.

With backlog refinement your team have a chance to shape how you want to work.

There’s an opportunity to find a backlog refinement rhythm that works for your team and helps you to increase or maintain sprint velocity.

Here are some of the key takeaways about backlog refinement (otherwise known as the TL;DR edition):

Now you should be ready to refine your backlog like a pro.

One day, you might even agree with me that backlog refinement is the most important agile ritual!

If you found this article useful, please consider sharing it with your team or others in your network! 🙌

Is there anything else that should be in this guide?

Let me know here 💌

In the meantime, happy refining!