Scrum Anti-Patterns: Large Product Backlog

Image of the Scrum product backlog anti-patterns for certified product owners

A design pattern is a description of a solution to a recurring problem. It outlines the elements that are necessary to solve the challenge without prompting the reader to address the issue in a specific way.

Unfortunately, we also regularly see recurring patterns of ineffective behaviour. These are called anti-patterns. They get your hopes up, then leave you with a bigger mess to clean up than what you started with. Learning how to spot anti-patterns will save you time, frustration, and antacid medication.

The following is an exploration of one of the most common anti-patterns.

Anti-Pattern¹ Name: Large Product Backlog
Aliases: Wishlist, Too Many Promises, Electronic Backlog Tool (e.g. JIRA, Target Process, etc.)
Scale: Team and across multiple teams
Related Anti-Patterns: Product Backlog Refinement goes on forever, Product Backlog used as a Parking lot; Feature Factory...
Potential Solutions:

Don’t record every suggestion from the client
Say “No” and “Not Now”
Search for older Backlog Items and delete them
Use a prioritization model that helps you make clear decisions about what is not included in the product

Why a Large Product Backlog Might Seem Like a Good Idea

Product owners (POs) new to Scrum are eager to please the customer, the end-user, and every stakeholder in their universe. They get asked for a feature, user story, or requirement (which hereafter I will refer to as a Product Backlog Item, or simply ‘item’). The person asking explains why they think it’s important and makes it clear that it must be added to the product backlog. The new PO adds it to the bottom of an ever-growing list.

At first, this works well and the customer/end-user/stakeholder feels satisfied because their item has been added to the Product Backlog and they will soon get their feature. However, a problem is brewing just underneath the surface of the situation. Over time, the Product Backlog grows from a manageable 50 to 60 items to 200 to 300. In some cases, I’ve seen clients with backlogs over 500 items long. Our brains just haven’t evolved to deal with and comprehend such long lists.

To illustrate this problem, I’m going to start by making a few assumptions: All of the items in the product backlog are of equal size, and a team averages seven to 10 items per sprint.² Let’s also assume two-week sprints. Arithmetic tells us that, to finish a list of 200 items, it’s going to take 20 to 25 sprints, or most of a year. In practice, it’s usually worse than this, because items lower in priority tend to be larger in size, so a 200-item product backlog might likely be over a year of work.

Imagine telling your customer, “If we add that item to the bottom of the product backlog, it will take eight to 10 months to finish.” That isn’t likely to delight them. However, simply adding it to the backlog without first discussing it in more detail, then having it be forgotten isn’t going to make them happy either. Customers can easily create wish lists, but the product owner needs to provide information and context that they don’t have, along with a healthy dose of realism, so that their perspective and expectations are attainable. Maintaining the product backlog at a manageable size ensures that.

Consequences of Using Large Product Backlogs

As the product backlog grows larger:

The lead time³ grows. As the lead time grows, the customer becomes dissatisfied, wondering why their feature is taking so long. Imagine lead time like ordering a car from a manufacturer — how long from the moment you place the order to when it’s delivered. Think about what it does to customer satisfaction if they must wait eight to 10 months for their new car.

The number of dependencies⁴ also increases lead time by creating delays. In a multi-team situation, dependencies between teams increase the likelihood of missing the target/goal. The number of dependencies also reduces the number of prioritization options. As the number of prioritization options is reduced, the lead time increases. As the number of dependencies increases, the likelihood of achieving goals decreases.

Product backlog refinement takes longer. The longer the list, the more time it takes to review, comprehend, and understand. As product backlog refinement takes longer, team members become less engaged. After all, who enjoys an activity that consumes more time with every sprint? As they become disengaged, they have a reduced understanding of the product backlog Items and are more likely to build a version of an item differently from what the customer wanted. Finally, as product backlog refinement takes longer, it is more likely that the team will misplace items that have become buried.

Prioritization becomes challenging. It is already difficult to do an effective job of prioritizing a list of 50 to 60 items, let alone anything larger. As you struggle to prioritize, items get misplaced in the product backlog and the customer grows frustrated, asking, “Where is my item? Why isn’t my item a priority?” Usually, they will then ask for their item to be made a priority (prioritization request) and, if you grant the request, it will increase the lead time on an item that someone else felt was a priority.

Pruning dead items becomes harder. As the product backlog grows larger, it becomes harder to spot the dead items (i.e. items that are no longer relevant). As dead backlog Items get missed, the product backlog grows ever larger in size. This is called a negatively reinforcing feedback loop.

Here are those effects all in one illustration:

Typical Causes

Absent product owner: The product owner has the job title, however, they put little time into performing the role
Product owner by committee: For example, four or five people think they’re the PO. They form a committee and just keep adding to the backlog
Product owner fails to say no to customers and stakeholders or isn’t empowered to say no
Saying yes to a new item without removing an existing item from the product backlog
Never pruning older items
Infrequent releases (less often than every three months) lead to unmet needs piling up and customers desperate to get their feature in the next release
Same item appearing in the product backlog multiple times, each phrased in a slightly different way, each with different supporting information
Failure to fix bugs when they’re found. Instead, adding them to the product backlog
Misuse of product backlog management tools. It’s easy to make really long lists that can’t be maintained. Made worse in that some tools offer, as a feature, a way of hiding small user stories as children of a bigger story
Lack of portfolio management (in a multi-team situation)
Failure to appreciate that there is no value in breaking down items for the longer term (months down the road) until it is closer to the time to do them
Executing on an existing predetermined plan vs. discovering the system the client needs. Some people believe that if you’re replacing a legacy system all we do is copy all the elements of the existing system into a new one. As anyone who has done this before can tell you, the needs of the users will have changed a great deal since the legacy system was developed. So even when replacing an application, we still need to spend time discovering what it's really needed for.

Solutions

Measure lead time
A tool that fades the older items in the product backlog, whereby if they haven’t been started after three to four months, they are deleted
Don’t break down product backlog Items that won’t be worked on for the next three sprints. If there are small items more than three sprints away, collapse them into larger items, then delete/archive
Product owner learns to say no, perhaps by saying “not now” or “If I say yes, it will likely take four or more months to finish. If it’s still important in three months, please ask again.”
Every time a new item is added, remove a less important item
In a multi-client/stakeholder situation, limit each party to four to five items in the queue at one time. To add a new one, an existing one needs to be either finished or deleted because it is no longer as important
Tease apart the existing mess with a story map and then throw away most of the now-extraneous details. Use the major items (often called major tasks) at the top of the story map as placeholders. If an item isn’t important in the next few months, don’t create individual user stories under the placeholders.
(Rarely) portfolio management
Find a coach to help you navigate challenges as a product owner and dysfunctions on your team.
Get certified! Scrum Alliance offers product owner, ScrumMaster, and Scrum developer certifications and support to help you navigate your journey as an agilist.

Notes

1 An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. ~ Wikipedia

2 Both of these assumptions are weak, however, the truth just makes the problems worse.

3 Source

4 Source

Additional References

Learn how to reduce the product backlog size here.

To explore the topic of anti-patterns more deeply, please see this growing collection of articles here.

Mark Levison is an author, Certified Scrum Trainer, and consultant with Agile Pain Relief Consulting. He can be reached through www.agilepainrelief.com.

If you’re a member of Scrum Alliance, get more insight into how teams work together in the Learning Journey course, How Successful Scrum Teams Deliver a Minimum Viable Product. You’ll get one SEU for completing this course to be used toward renewing your certification in the future!

If you’re not a member, please see the key benefits of Scrum Alliance certification and membership.

RL_23_scrum-anti-patterns-large-product-backlog