What is Backlog Refinement?

Have you ever held a project planning meeting where nobody knew which tasks to prioritise? Where nobody wanted to say how long they thought something would take to complete? And where no-one had a clear definition of “done”?

Many teams transitioning from waterfall to agile will know exactly what I’m talking about.

Backlog refinement might be just what you need for

  • More efficient meetings
  • Clearer priorities
  • Better sprint velocity

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, we’ve got you covered 😉

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


What is Product Backlog Refinement?

Before and after backlog refinement

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:

“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.”

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.

What are the Scrum Guidelines for backlog refinement?

Scrum guidelines for backlog refinement

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:

  • 🗓️ Backlog refinement is an ongoing process
  • ⏱️ Refinement usually consumes no more than 10% of developers’ capacity
  • 👩‍💻 Teams update the backlog throughout the sprint
  • 🌱 The backlog is a living artifact

And that’s it folks! 

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:

Who is Responsible for Backlog Refinement?

Product owner and development team build products together

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:

  • ✏️ Clearly expressing Product Backlog items;
  • 🗂️ Ordering the items in the Product Backlog to best achieve goals and missions;
  • 👀 Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • 🧐 Ensuring the Development Team understands items in the Product Backlog to the level needed.

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.

Why is Backlog Refinement Important?

Backlog refinement might be the most important agile ritual of them all.

And that might be an unpopular opinion, but stick with me on this one...

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.

Heck, 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 speed.

wallace and gromit laying tracks

Now, refined backlog items are 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.

How often should Backlog Refinement happen?

That’s the million dollar question! 💰

The fact is that there are no hard-and-fast rules.

As we know, the Scrum Guide doesn’t give us much guidance.

But there are a couple of practical things you can do to give backlog refinement a bit of structure.

Schedule a regular refinement meeting

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:

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

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. Find refinement rhythm (1)

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. 


But build a habit of individual daily refinement

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

Backlog questions to reach for

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.

Discussion in the Parabol backlog
Backlog items being discussed by the Parabol team directly in 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.

What are the Main Backlog Refinement Activities?

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.

Backlog Refinement Funnel (3)

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.


Add backlog items so everything is recorded

Entering the backlog

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:

Is the Product Owner exclusively responsible for adding backlog items?

Or

Is the whole team responsible for adding backlog items?


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

  • 🧱 How your team is structured
  • 👾 What types of items the backlog includes
  • ✂️ How backlog refinement takes place

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. 

Bugs and enhancements coexist in the Parabol backlog
In Parabol’s backlog product items, design items and bugs coexist.


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. 

Crafting user stories to align products with people

Epics and stories

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.

✅ As a Scrum Master, collecting anonymous Sprint Poker effort estimations will prevent my team copying each other and help us estimate effort more accurately.

⛔ Build anonymity function for Sprint Poker product

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:

❤️ Keep work focused on the users: Regularly speaking in terms of user concerns helps to show the whole team how their work matters and will impact users. It also helps to ensure that all backlog items are serving a genuine user need.

💬 Explain the outcome in clear language: Let’s say your colleague Tom has added a new backlog item. He’s scribbled a few notes about what the item concerns and some tasks that make sense only to him. That’s not useful for the rest of the team -- and especially non-developers! Writing user stories helps everyone to understand what the item concerns and what the outcome will be.

🎨 Encourage creative solutions: User stories are a creative way of framing product improvements. And one of the great benefits of writing user stories is that they help people focus on the end goal. User stories help prioritise creative routes to the end goal rather than specifying how to get there.

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.

T-shirt sizing helps build a rough estimate of project size

T-Shirt Sizing

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.

Sprint Poker helps build more accurate effort estimates

Poker

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 about it.

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.

Acceptance criteria and estimation

Here’s an example of the acceptance criteria and estimated effort documented in one of our backlog items for the design team

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.

Prioritisation tells everyone what’s important

Backlog matrix (1)

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:

"The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint."

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

 

Conclusion

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.

4c73z5

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):

  • 🔁 Backlog refinement is a continuous process that takes up no more than 10% of the development team’s capacity
  • 📝 Backlog refinement helps your team prepare items to be taken into the next Sprint by adding detail, user stories and effort estimations.
  • 👑 The Product Owner is responsible for the backlog, but the development team should work together on refinement.
  • 📆 Teams should schedule a regular time to meet and discuss the backlog – this could be for a short time after the daily standup, weekly, or once per sprint.
  • 🎯 Items may enter the backlog from multiple sources: the product roadmap, customer feedback, feature requests, customer support, or as ad-hoc product enhancement ideas.
  • 🎨 Crafting user stories helps teams focus on how their work will benefit the end-user.
  • 🃏 Estimation techniques, such as T-shirt sizing or Sprint Poker help teams estimate effort needed to complete a backlog item.
  • 🏅 Prioritising backlog items as a team ensures everyone is aware of the product direction
  • 🚅 Effective backlog refinement helps your team maintain or even improve sprint velocity

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! 👋 

 

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.