6 Backlog Management Techniques

An Agile backlog (back log) is a prioritized list of features, bugs, technical work, and knowledge acquisition needed to meet the desired functionality in the product. Your backlog is the roadmap for your product.

How do You Manage a Backlog?

Backlog management is the process by which the product owner (often in collaboration with others) adds, adjusts, grooms, and prioritizes backlog items within the backlog to make sure the most valuble product is shipped to customers.

An oversized product backlog is a problem. It impedes innovation. It slows time to market. And it causes frustration in even the best Agile teams. In this post, we'll cover common challenges of oversized backlogs and how to fix them.

Download an expanded PDF of this article.

Agile Backlog Management Challenges

In an Agile development organization, the main tool to manage the roadmap and gain predictability is the backlog. But if it grows uncontrollably, the value it provides diminishes.

An unreasonably long backlog is a major pain point for many Agile teams. By virtue of the shear amount of information, it becomes unmanageable and irrelevant. It will then be abandoned. Teams will resort to reactive sprint planning. In turn, they'll lose sight of the long-term goals and end up in a very task-focused environment. Because it's much easier to think about what you need to do now than what you need to achieve in the distant future.

An overly large backlog causes many problems.

Maintenance costs — We suffer from a blindness to queues. Queues incur cost; each item will continuously require a little attention to remain valid. Grooming a fat backlog can seem like an insurmountable task, which means that it is omitted. Eventually this leads to the entire backlog becoming obsolete.

Value reduction — Each item, in a backlog of tens of thousands of items, will seem insignificant. Adding a new item will feel pointless. When backlogs get too big, they become a trash bin where all work you want to do, but never will, ends up.

Inhibited innovation — Since reorganizing a big backlog is such a chore, brilliant ideas are either added at the front or the end of the backlog. Adding items to the front means that you are invalidating the rest of the backlog, while adding them to the end guarantees  they never will be done.  

Why Do Product Backlogs Get Too Big?

With these problems in mind, let's look at how backlogs become oversized. Truth is, there is not a single cause, but often a combination.

Hoarding — Humans are hoarders by nature. We have a hard time throwing away anything, especially good ideas. The key to managing the backlog is not to know what should go in, but deciding what should go out.

Information need —There is a lingering belief that keeping track of everything at a granular level gives us a good idea of the scope. However, as responding to change is an important part of agile development the further in the future we have plans the less certain they are. Thus the granularity needs to reflect that. In the term DEEP, which is often used to describe a good backlog, the D stands for Detailed appropriately and describes the solution to this problem.

[RELATED CONTENT: BACKLOG GROOMING FOR HIGH-VALUE PRODUCTS]

Dependency resolution — When we are not truly Agile we strive toward resolving dependencies far into the future. To identify dependency chains, we break down large items into their components and reduce goals into tasks. This has a double-negative effect on backlog quality. First, it makes the backlog balloon. Second, it means that our backlog is no longer value driven, and instead heavily focused on what work we need to do.

No commitment to product owner role — Most products organizations have way too few product owners in comparison to the team size, and they have limited time to manage the backlog. The product owner responsibility is something that shouldn’t be taken lightly.  

6 Tips For a Lean Backlog

Here are a few action items for improving your backlog size.

1. Take the Product Owner Role Seriously

There should be one person — no more, no less — responsible for the backlog of each scrum team. Ideally, that person is only responsible for one team backlog as well. That person needs to have plenty of time availablefor maintaining the backlog in collaboration with the team and external stakeholders. She needs to be knowledgeable about the product and have the authorityto make decisions within the backlog without involvement of other parties.

2. Limit Design in Process

A good starting point would be to start looking at your Design in Process (DIP) inventory, a term coined by Donald Reinertsen. What you want to do is set a limit as to how many items you can have in the backlog. There is not a size that fits all. But a starting point would be size per product owner (PO). Since a PO is mainly responsible for a backlog, her capacity to administer the information is the limitation. Thus, a large product with ten PO’s, responsible for different areas, could have a backlog that is double the size the backlog of a product with five PO’s. Generic advice? Dunbar’s number gives good guidance in this situation. It says that one PO could handle around 150 items at any given time. We should also consider DIP for amount of work to ensure that our pipeline isn’t planned for years and years as this could seriously inhibit innovation. However, it’s hard to give a generic advice on how long a roadmap should be as it depends on a lot factors, such as product type and market maturity.

3. Decide How to Manage the Backlog

Create a simple and clear strategy of how you will manage your backlog and involve the team in that process. The product owner holds the responsibility to maintain the backlog, but she is not the only one that contributes to the vision. Everyone on the team can and should contribute and continuously participate in the process of keeping the backlog fresh. For this to work, everyone needs to have a rough understanding for backlog as this is the product’s vision and roadmap.

4. Make Decisions

Restrain yourself from entering every idea that comes up, keep it in your head and if it still is in there after a week it might be worth adding to backlog. In association to that you should have a soft “one in, one out” policy as you are hitting the DIP limit you have set for yourself. And yes, it is hard to discard things but having that ability is an important trait of a product owner.

5. Work With an Aging Idea Funnel

A product backlog, and a team backlog, can be divided into several stages where the DIP limit could be more difficult the closer they are to implementation. The simplest approach would be to dedicate one portion of the backlog to new ideas, and another portion which is more thoroughly groomed and restricted in size. Give the ideas an age limit so that the ones that are not being prioritized are disappearing over time to avoid flooding this part. When the idea is moved to the next part, it indicates a commitment from the PO that this idea will actually be implemented eventually.

6. Follow Your Own Rules

If you apply strict DIP limits you might be tempted to bypass your own rules and instead pack an abundance of information into each item. Don’t do that.

Apply What You Learned — for Free

Hopefully, this will help you take your product backlog from being an unmanageable colossus to a lean and manageable roadmap helping you accelerate innovation and deliver the highest quality product possible.

Ready to try it out? Get a backlog management tool that is free for small teams.

Manage Your Backlog in helix plan (formerly Hansoft)