What is a Product Backlog

Product Backlog is an odd term. When I first heard it I thought it was a bad thing. The word backlog has a negative vibe to it.  When someone talks about backlog the picture that comes to mind is that of a mountain of things with things falling apart everywhere. That isn’t correct when we think of backlog in terms of software development. Though if you are not doing your work your backlog can resemble a mountain or a volcano that is just waiting to explode.  🌋

What is Product Backlog

In the simplest terms, Product Backlog is a list of items that the product team needs to work on. These items can be new product ideas, updates to existing products or fixing things that are broken in the product. Managing a product backlog is one of the hardest things to do for a product manager. It is because you are trying to do two things:

Who manages it

The product team is responsible for managing the product backlog. Your team might have one backlog or multiple ones. The goal is for the product team to get a unified view of everything that needs to be done in the product. It is only then that the product team can make informed decisions that are consistent with the organizational goals.

If you work for a small company which has one product then it is possible to work through a single product backlog. However if you work for a large company with multiple product lines then you will end up having multiple product backlogs. Each backlog is managed by a different product manager. In such situations it becomes even more important for all the product managers to work collaboratively.

Who has input on it

There are a variety of internal and external sources that influence the product backlog. Let’s look at some of them:

Why is it important

As you can see there are a lot of sources from where you get input on what to work on. Let’s try out a short exercise for a minute. Take out a piece of paper and write down items that need to be developed for your product in the next six months. Now pass it around to your product team and tell them to continue building on that list. When they are done pass the sheet around to all the stakeholders identified in the above section. Soon you will run out space on the sheet of paper 😅.

The point here is that there will always be a ton of things that you will want to do with the product. But no matter how big your product and engineering teams are you will not be able to work on everything on that sheet of paper. And it will keep growing beyond a single sheet. You need a better process to manage this list. That’s where a product backlog comes in. It helps you:

Product Backlog and Time Management 

Are all items in the product backlog equal? No they are not. There is no way you can spend the same amount of time on each item in your product backlog. If you start doing that you will run out of hours in a day. So how do you distribute your time among all the ideas in the product backlog? When an item comes to a product manager in the form of a new idea or update they should do a sanity check on it. One way to do it is by asking yourself the following questions:

There is no hard and fast rule on how much time you need to spend on each question. You need to be smart in the way you work. At the first stage you shouldn’t spend days looking at each idea. Try to summarize your findings in one page. This will help you focus on things that are the most likely to be developed.

Types of Product Backlog

You can have as many different types of backlog that you need. At the end of the day it is a list. Whether one or more helps you get the job done is upto you. Some of the common types of backlog that I have seen follow the product lifecycle. Think about it for a minute. You get an idea, you look into it and if it makes sense to invest in it makes to the development queue. Otherwise you park the idea. On those lines you can have the following types of backlog

Idea Backlog

It is a list of all the ideas that the product team needs to look into. You will look at the idea from a user and business perspective and stack rank them. At the top will be the idea which is most important. The product team will look at the idea backlog and go through all the details at a regular cadence. Ideas will be moved to the product backlog based on their importance.

Product Backlog

A common misconception is that everything in the product backlog will be developed. The product backlog is a list of things that the product team would LIKE to work on. They have done the due diligence and have come to the conclusion that working on these items is important. But importance is relative and the ideas will keep coming. The point I am trying to make here is that you have to be smart in the way you manage your time. Items at the top of the product backlog are more flushed out then those lower down.

The items at the top are neatly broken down into epics and user stories and have been discussed with the development team.

Development Backlog

This is the work queue for the development team. They pick up items at the top of the backlog to start working on. Items here have gone through grooming sessions and stories further broken down into tasks and subtasks.  The product team should try their best to not move things around too much in the development backlog.

Icebox

Overtime as your product grows your backlogs will keep getting bigger. By now we all agree that you can’t work on everything 🤪

What you will start seeing is a growing list of items at the bottom of the backlog. These are low priority items that you want to work on “someday” but that someday has not come up in years. In such a scenario some product teams put these items in the Icebox. This helps them keep their product backlog more presentable and manageable. Other teams prefer to delete these items.

Is your backlog working for you?

Having a backlog and a backlog that works are two very different things.

Building a backlog is the easy part. The real challenge lies in keeping it current week after week. Product Managers get so caught up in what they need to do now that they are unable to spend time on their backlog. What ends up happening is that the product backlog no longer reflects the needs of the user and business. Nobody really knows what the most important thing to work on is anymore. You start getting into the habit of writing one product requirement after another. You stop looking at the unified view that the product backlog provides. This results in a host of problems:

This can be avoided by doing the following:

Conclusion

Managing a product backlog is one of the hardest things to do for a product manager. It is because you are trying to do two things:

But if everyone on the team believes in its value, then over time it will help you become a customer centric team.