Skip to main content

How to Work with the Product Backlog

comparison of product roadmap to 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 ‍♂️

Product backlog as a secret superpower

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:

What is a Product Backlog?

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

Parabol Product Backlog

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:

  • 📚 User stories for new product features
  • 📦 Product enhancement ideas
  • 💰 Technical debt
  • 🐛 Bugs
  • 🎨 Design tasks

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:

  • ✅ Aligned with the product roadmap
  • ✅ Detailed and prioritised
  • ✅ A tool that serves your team and helps you meet goals

A product backlog should not be:

  • ❌ A place to list all the product ideas your team has ever had
  • ❌ A disorganised place to record half-baked thoughts
  • ❌ Something you ignore for the whole sprint

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

What’s the Purpose of a Product Backlog?

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:

  • 🧱 Help break the product roadmap down into manageable and actionable steps
  • 📜 Act as a place to record additional product enhancements or features not reflected in the roadmap
  • 💎 Let teams inject transparency into the agile process and equip everyone with the knowledge to discuss what should be prioritised

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

Product roadmaps vs product backlogs

The product roadmap tells teams where they need to go

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 product backlog details how the team is going to get there

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.

How to manage the product backlog?

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:

  • ➕ Adding items to the backlog
  • 🏅 Prioritising the backlog on an ongoing basis
  • 🔦 Refining or grooming the backlog
  • 🗑️ Scrubbing items from the backlog

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

1. Adding items to the backlog

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.

example of adding an issue in the parabol backlog
When adding a backlog item at Parabol, the form is structured to ensure items are appropriately detailed and are comparable

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:

  • ‍♂️ Backlog items are not duplicates or included in other user stories
  • Items are important enough to go into the backlog
  • New backlog items are written up clearly and with enough detail that the whole team can understand them
  • Team members inform colleagues about new backlog items or initiate a discussion about whether an item should go in the backlog before adding it

2. Prioritising the backlog on an ongoing basis

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.

Backlog matrix (1)

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

  • 👍 Prioritise items that are easy to complete and add high value
  • ✍️ Consider items that are difficult to complete but add high value
  • 👎 De-prioritize items that are easy to complete but low value
  • 👋 Relegate items that are difficult to complete and low value

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.

3. Refining or grooming the backlog

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:

  • ✍️ Adding detail to backlog items so everyone can understands the tasks to complete to ship a piece of work
  • 📚Writing user stories so everyone understands how the end user benefits from a piece of work
  • 👩‍👧‍👦 Breaking epics into smaller backlog items to ensure they are a suitable size for future sprints
  • 🗳 Estimating effort to develop an idea of how long an item will take to complete
  • Devising acceptance criteria so everyone knows when an item is ‘done’

4. Scrubbing items from the backlog

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:

  • 🚀 The issue or idea did not gain traction or appeal among team members
  • 🥵 The item was categorised as low-value, high-effort 
  • ✅ The same thing was already accomplished via a different backlog item
  • 🐞 The item is irrelevant because the product has since evolved

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.

Making sure the backlog is DEEP

Product backlogs should be DEEP (3)

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:

  • 📋 Detailed: Items have enough detail to be comprehensible by the whole team
  • 🃏 Estimated: The team knows the rough size of backlog items so sprint planning can be more accurate
  • 🚀 Emergent: The backlog is always changing and moving forward as new items based on user feedback are added to it
  • 🥇 Prioritised: The most important items are listed at the top and are worked on first

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:

“To ensure that the product backlog is DEEP and stays that way, you have to groom or refine it regularly. Grooming the product backlog is an ongoing, collaborative process that involves the product owner and team.”

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.

Conclusion

Benefits of working with the product backlog

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

  • 💎 Create transparency over the product roadmap and the steps needed to reach goals
  • 🗳️ Build consent for specific increments of work
  • 👀 Maintain oversight over long-term and short-term milestones
  • 📆 Remain organised amid busy sprints
  • 🏅 Prioritise tasks effectively

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: