How to Manage a Large Product Backlog

Before we dive into strategies for effectively managing a large product backlog, remember that a large backlog is an anti-pattern in and of itself: The larger the backlog, the harder it is to manage. As product owners, we should try to avoid and prevent this as much as possible. This is why we’ll try to address the ways of preventing a backlog from growing (too) large, and the ways of managing it when it does.

Signs that your backlog is growing too large include:

• The backlog has grown to hundreds of items (the exact “unmanageable” quantity varies by scrum team and product)
• You don’t want to show anyone the list because it’s so unruly
• You can never seem to find the item you’re looking for 
• The development team feels that they can never make impactful progress on the backlog
• The length has caused you to lose track of what is a high priority
• It’s impossible to tell which items have been refined and prioritized, and which are brainstorming ideas
• The list looks random and chaotic instead of ordered and well-organized
• It’s nearly impossible to find enough time to prioritize the backlog because of the number of items 

Prevention Is the Best Medicine

Going back to basics, the Scrum Guide defines the product backlog as “...an emergent, ordered list of what is needed to improve the product” and “the single source of work undertaken by the Scrum Team.” Product backlog refinement is defined as “..the act of breaking down and further defining product backlog items into smaller, more precise items” and “...an ongoing activity to add details, such as a description, order, and size.” 

A detail that is not always obvious to product owners right away or explicitly stated in the Scrum Guide is that in addition to saying “yes,” product owners need to say “no.” On top of adding details and refining product backlog items into smaller and more precise items, product owners sometimes need to cut out, remove, or decline them at the outset.

In an ideal world, we wouldn’t have large product backlogs in the first place, and this emerging document we’re in charge of would never grow in size so much that it becomes (too) hard to manage them.

In practice, we often have to deal with extensive backlogs. For instance, we may join a new team and “inherit” a large product backlog, we may consult for an organization or team that has a large product backlog, or maybe we didn’t manage to keep it from getting out of hand for various reasons. 

We’re all humans, after all, with our unique organizations, products, and contexts, and this is not a place to judge. The following steps and principles proved useful to me and I hope they are helpful to you as well.

4 Steps to Rein in the Product Backlog

1. Split

The first step is making sure that the product backlog in question is indeed a single, coherent entity. Is there room for unbundling or splitting the backlog itself? 

As time passes, and products develop, they naturally gravitate toward serving more experiences for more user groups. In cases where it makes sense, don’t be afraid of splitting the backlog (either “only” internally, from the backlog perspective; or literally by unbundling a product into separate products from the user perspective).

If and when to unbundle, of course, depends on the context, and there is no single formula. It’s also not a precise science but rather an art.

A good rule of thumb is to look at the type of needs or problems a product is solving for, and at user groups. If either needs or user groups are visibly different, splitting could be a good option. Many times, we should have a product portfolio rather than a single, very large product serving very different users with very different needs.

Some of the significant examples would be Uber – unbundling Uber Eats from the main app; Foursquare – launching a separate app for check-in called Swarm; LinkedIn – launching a separate app for job search; and Meta (previously Facebook) – unbundling Messenger.

2. Limit

We can experiment with limiting what goes or stays in a backlog. Setting limits is a great exercise and will help keep the backlog in check. There can be different limits that you come up with, but the most common are often based on purpose, age, and number. Based on the context, I suggest trying some or all of these or maybe a completely different limit.

Purpose limit implies focusing on a clear, measurable outcome such as “increasing the number of users from X to Y,” or “reducing churn by X%,” and then not adding items that do not drive the product towards this goal, or removing the existing ones that don’t address it. Additionally, the Scrum Guide defines “Product Goal” as a single “long-term objective for the Scrum Team.” This is a good moment to remember this, and decline or remove any items that don’t serve the product goal.

A limit in the number of product backlog items is arbitrary, but based on context, we could say X open items are the maximum – and then either decline any new items in the case of lower priority items or “trade” them for an existing item if they are higher priority. 

Age limit is yet another arbitrary but useful limit, and it is reactive: We don’t allow items to become stale and open for too long (versus the previous limits where we also proactively decline the non-fitting items). If such information is easily available, the age limit could be set at the product backlog level (average or median age) or at the backlog item level. Most modern tools give this type of information.

Finally, note that limits are healthy in moderation: They can bring out creativity and a solution-oriented mindset, but do not overdo them just for the sake of setting limits.

3. Eliminate

Once the limitations are set, and the product backlog has been split into two or more backlogs (if appropriate), then the third step is straightforward: Comb through the backlog, find any item that does not fit, and remove it. 

A good practice is to prune out so-called “zombie items.” They are backlog items added long ago, that end up being forgotten and irrelevant for today’s context. “Zombie items” are ideal candidates for elimination.

Additionally, based on the previously set limits, we may eliminate items older than X days or weeks, items unrelated to our product goal, and so on. We should also eliminate any duplicates, or, as another great option, consolidate them.

4. Consolidate

The last step is a useful activity for managing the product backlog – consolidation. Work to consolidate duplicate, similar, or related items into a single item. Consolidation helps reduce clutter, and it can be especially helpful for items that are too small or too specific to be useful on their own but could still provide value if combined with other related items. 

Look for product backlog items that have similar goals or requirements, then merge them into a single item. Make sure no essential details are lost in the process, and in the case of apparent duplicates, feel free to simply eliminate the duplicate item(s).

2 Principles to Keep in Mind

The four steps were concrete actions to take, while the following principles are more of a general direction to keep in mind as we work.

Principle 1: Be Mindful of the Hierarchy

Different teams and organizations categorize and structure their product backlog items differently. For instance, a common way to organize hierarchy is the User Story Map or dividing the backlog into “Now, Next, Later” (this is also a roadmapping approach).

Each implementation of scrum is unique, but many scrum teams utilize user stories as the main type of product backlog item. 

So how can it show hierarchy?

It is important to have a clear product backlog hierarchy, especially when managing a large backlog, as it helps us orient better. For the purpose of this article, we will look into the most common types of product backlog items, their place in the hierarchy, and illustrational examples below.

Theme:

A theme is the largest product backlog item, the most abstract one, and it encompasses multiple epics. Not all organizations use themes, but they can be very beneficial in the context of large product backlogs. For a banking app, two themes could be “loans” and “payments” – where each of them would contain multiple, more concrete epics.

Epic:

Epics are the second largest backlog item, and they are grouped into themes. They are more concrete but still large. Under the “loans” theme, our banking app could have epics such as “cash loan,” “mortgages,” “car loans,” “point of sale loans,” and so on; or it could have epics such as “loan application,” “loan approval” and similar. Organizing epics is highly dependent on the organization’s context and product owner’s sense-making. There are no outright wrong or right answers.

User story:

A user story is the most commonly used form for product backlog items. It is clear and concise, coming together with a definition of done. Oftentimes, user stories are written following a well-known story template:

AS A [user|persona|system],
I WANT TO [action].
SO THAT [value|reason|need behind]

For example, we could add the following user story under the “loan application” epic: “As a loan officer, I want to quickly check a customer’s credit score, so that I know if I can pre-qualify them for a loan.”

Subtask:

As described in the Scrum Guide, “Developers plan the work (...) by decomposing Product Backlog items into smaller work items of one day or less.” These smaller work items are usually called subtasks (or sometimes tasks). 

Subtasks can be technical, but they need to support the overarching user story, which is value-driven. Subtasks are concise and concrete. For example, “integrate with credit bureau API” could be a subtask for the previous user story. Technically, they are elements of the sprint backlog, not the product backlog. They describe the "How" rather than the “What and Why” of a user story.

Bug/defect, spike, task:

There are quite a few (potential) product backlog items that are common, but may or may not be used depending on the particular organization and the team(s). For instance, there are teams that don’t consider a spike to be a valid backlog item, and even more teams that don’t think a task belongs in the product backlog.

1. Bug/defect 

How to incorporate bug fixes into a product backlog? How to track and prioritize bug fixing activities? It is a whole discussion in itself.

2. Spike

Spikes are items reserved for research and gaining technical knowledge (for example “compare API A and API B that allows credit score checking”).

3. Task
   Some teams also have tasks as standalone items, and even track non-product, non-research related work through them (for example “purchase subscription for API that allows credit score checking”).

If and how your team chooses to include these (or other) types of items in your product backlog is up to you and the team. Experiment to discover what is most effective.

Principle 2: Be Mindful of Granularity and the Level of Detail

Not all product backlog items should be equally detailed, nor equally broken down into the most granular work items. If all product backlog items are too verbose and overly detailed, this will burden the backlog and make it cumbersome to manage and understand. 

A good rule of thumb here is to think of hierarchy and relevant point of time for each item: the higher up in the hierarchy (themes, epics) – the less detail needed; the further down in the backlog and therefore unlikely to be worked on anytime soon – the less detail needed. 

Of course, every product backlog item needs to be independent and concise, but when it comes to epics or themes, we need to capture the essence, keep it brief, and define more closely through belonging items (e.g. user stories).

Furthermore, when it comes to items likely to be deferred into the more distant future – only the essence is needed. Our reality changes rapidly, and we learn more with time. Refining items in the more distant future at a very detailed level is a lot of effort, and the plans on how the items are to be done (or the items themselves) may become obsolete by the time we get to them.

Bringing It All Together

When dealing with a large backlog, product owners should consider these four options to manage it: 

• Split it into separate backlogs when appropriate
• Experiment with different types of limits to manage the number and age of items in the backlog
• Eliminate irrelevant items
• Consolidate similar, closely tied, or duplicate items 

While doing so, they need to remain mindful of the appropriate hierarchy of the product backlog, and appropriate level of detail and granularity of its items. 

It is important to prevent a product backlog from getting too large in the first place by being selective and intentional about what is added to it. Hopefully, these steps and principles will be useful if you must manage a (too) large backlog, as we all do at times.

–

Interested in more tips for managing a product backlog? Please see how to refine a backlog to sharpen your knowledge of this important scrum team responsibility.

If you're an experienced Certified Scrum Product Owner and you're ready to take your knowledge and skills to the next level, becoming an Advanced Certified Scrum Product Owner equips you with the tools you need to advance and thrive in your career.

Become an Advanced Certified Scrum Product Owner