How to Work with the Product Backlog

Imagine for a second that you were a superhero and you could see into the future. What would you do with the power of foresight? 🦸‍♀️ 

Perhaps you’d bring humanity a cure for cancer? Maybe you’d win yourself the lottery? Or you might warn everyone about an upcoming zombie apocalypse ‍♂️

Well, much as I hate to break it to you, the product backlog isn’t going to make you a millionaire or help you save the world. 

But it can help you see into the future.

And it could just be your secret superpower, should you choose to claim it.

In this article, we’re going to cover everything you need to know about working with the product backlog, including:

The product backlog is a prioritised list of all the possible work that can be done to release a particular product.

While the product roadmap tells teams where the product aspires to go, the backlog is a prioritised list of all the work needed to get there, along with other product ideas.

Your product backlog may include all manner of items, including:

The most important or most urgent items are listed at the top of the backlog, with less important and less valuable items falling towards the bottom.

In essence, the product backlog is the authoritative source of all changes that could be made within the product. It helps teams line up what they will work on next.

A product backlog should be:

A product backlog should not be:

Simply put, the backlog helps the team decide what they need to work on next.

Having a product backlog helps everyone on the team understand what’s important and gain transparency over what work is up next.

The goals of having a product backlog are to:

It’s helpful to think about the product backlog through its relationship with the product roadmap.

It charts the road ahead and tells teams on a high level what they need to build and why.

If you’re setting out on a long journey, the roadmap shows your intended end destination and all the pit stops along the way.

In reality, the product roadmap is aspirational. You may make a detour here and there and end up at a slightly different destination after some course-correction. But the roadmap at least gives teams a direction to set out in.

The backlog charts out and prioritises all the individual efforts that may be needed to reach various goals and milestones.

This means that, as a loose rule, your product backlog should serve the end goal of your product roadmap. That’s not to say the general direction may change during the course of a sprint.

Unlike the roadmap, however, the backlog contains much more detail, and also related issues or ideas, which have a lower priority in the backlog.

The term ‘backlog’ is a rather unfortunate one.

For many, it conjures up images of stagnating tasks the team will never get around to. Or an intimidating mountain of jobs to be done that seems impossible to scale.

But it shouldn’t be that way.

If you have negative feelings about the backlog, it probably isn’t serving you well and you need to find a new way of working with it.

The backlog shouldn’t be a source of confusion. It should be a comforting source of knowledge about what to do next.

Whether you’re a developer or a product owner, the backlog is your ultimate to-do list.

The product owner is responsible for managing the backlog throughout the course of a project.

According to Roman Pichler, “the Product Owner is the one and only person responsible for managing the Product Backlog”.

While that may be the case, the backlog isn’t their domain alone.

The product backlog is what bridges the gap between the product owner and the development team.

So the product owner or product manager will work intimately with the development team to prioritise and refine the backlog during the sprint.

Managing the backlog is usually a team effort!

The product owner relies on the developers to provide on-the-ground estimates of how long something will take and the steps needed to ship a piece of work, while the product owner provides overall direction.

Managing the product backlog can be grouped into four main processes:

Let’s go over those processes in a bit more detail. 

While the product owner is responsible for ensuring the product backlog is aligned with the product roadmap, most teams own the backlog collectively.

In smaller, more intimate teams, everyone may be empowered to add backlog items and refine them during the course of their work. In larger teams, with more stakeholders, it makes sense to have defined structures and rules around the backlog.

Some teams assign specific roles who are responsible for adding backlog items that emerge from customer feedback. Other teams have an approval process for adding items to the backlog at all.

For example, at Parabol, the product team has overall responsibility for the backlog, so if someone from the growth team wants to add a backlog item, we ask and get their blessing first

It’s beneficial for teams to have an established process and structure for adding backlog items. This helps to avoid items being poorly explained, incomplete, or inappropriate for the backlog.

When adding backlog items, team members and the product owner should make sure that:

The product backlog is a ‘living artifact’, according to Scrum methodology.

That means it should be constantly changing during your sprint, as detail is added and priority levels are discussed.

The backlog itself should always be in priority order, with the most important and refined items at the top. This allows your team to see which parcels of work are ready and most important to be pulled into the sprint.

Prioritisation is always a negotiation between team members, but the product owner should step in and take the lead on that process to ensure the right things are being prioritised in line with the roadmap.

Using a backlog prioritisation matrix can help along difficult discussions about which items to prioritise. Sometimes there may be uncertainty about what to work on next. Other times, you may feel like all items are urgent.

You can group your backlog items according to four criteria, which can help you to come to a conclusion in your prioritisation sessions:

Prioritisation, like other backlog activities, is an ongoing process. So don’t be intimidated when your backlog has 100+ items in it and you feel they all have to be prioritised.

Instead, focus on what’s new in the backlog and prioritise those items against what’s already there, since the backlog should already be in priority order.

Backlog refinement is the process by which your team review the backlog and take steps to shape items included in it.

The purpose is to ensure that items in the backlog are the right size, have clear acceptance criteria for being considered ‘done’, and have an effort estimation attached to them.

When issues include these details, the team can make better decisions about how many and which issues to tackle in the next sprint.

It’s up to individual teams to decide how often to refine the backlog. Refinement is meant to be an ongoing process. But it can be hard to dedicate ‘ongoing time’ mid-sprint.

Many teams prefer to time-box a session once per week or once per sprint. If that’s not enough for your team, try something different.

Backlog refinement is composed of a few activities, including:

Sometimes when it comes to prioritising items or refining the backlog, you’ll realise how long it has become. At the bottom of your backlog are likely a number of items that aren’t getting much love.

It’s good practice to give the backlog a good scrub once every month or so. This helps keep the backlog fresh and up to date.

There are many reasons why backlog items flounder at the bottom of the list.

Here are some criteria for deciding when an item should be scrubbed:

You can take items out of the backlog by simply storing them somewhere else. That gives you the opportunity to bring them back from the dead if they become relevant again.

Part of the scrubbing process can be automated to make your life a bit easier.

At Parabol, we set up a bot that alerts us if no comments or actions have been taken on an item in over 6 months.

That gives us a clear criteria for having a discussion and eventually scrubbing or re-prioritising those items.

Sometimes teams struggle with the backlog, because during the sprint, they want to push ahead towards the deadline. This can lead some teams to neglect the backlog until sprint planning comes around again.

When you’ve got a series of tasks in front of you, it’s hard to step back and look even further into the future.

What’s more, product ideas or suggestions often come to us at the most inopportune of times: when you’re in the shower or hard at work on another task. There’s a temptation to scribble something down in the backlog and add detail later.

When you come back to that item later in the sprint, you can’t remember what it was. And if you can’t work out what it was, then neither can your team members.

DEEP is a useful mnemonic to help you work with the backlog better. It stands for:

Ensuring the backlog is DEEP, requires regular work from your team, who should be spending time adding new items and shaping up existing ones during the course of the sprint.

In the words of Roman Pichler:

There’s some good news here.

The more ‘DEEP’ a backlog item is, the more likely the team are to work on it because there is already a clear purpose, user story and acceptance criteria.

Making backlog items DEEP helps minimise a back and forth of clarifying questions that can slow teams down.

The product backlog is one of the most important artifacts agile teams have at their disposal, because it helps them:

And much more.

To get the most out of the product backlog, become friends with it.

You want to be working with the backlog, not against it.

So make sure it serves you and your team.

Just think of how much easier your life will be when you can see two to three sprints into the future.

Now if that’s not an agile superpower, I don’t know what is.

Want to read more about managing your backlog?

Check out our related articles: