Scrum Anti-Patterns: Large Product Backlog

By Mark Levison

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-Pattern1 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.2 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³ 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

Sprint Goals Provide Purpose

By Mark Levison

Image attribution: Agile Pain Relief Consulting

Go Beyond Merely Completing Work Lists

A Sprint should be so much more than just completing a number of User Stories or fixing bugs. If your Sprints are merely about ticking off items on a scattered work list without having a shared understanding of why they’re important or what purpose they serve, your Development Team will struggle to keep focus in the short-term and will take longer to become highly effective in the long run.

Research shows that people, whether acting individually or as a team, achieve more when working toward an objective that is specific, challenging, and concrete.^[1] For that, we need clear Sprint Goals.

Why Do We Have Sprint Goals?

In Scrum, we ask a Team to undertake Sprint Planning to agree on what they will achieve in the next Sprint, based on their expected capacity. As an outcome of this, the team should leave their planning session with a clear goal.

This provides stable direction, with flexibility to re-evaluate work, throughout the Sprint. It is the Why of a Sprint, establishing purpose and commitment.

By participating in setting a Goal, Team members experience a sense of ownership of it and gain a better understanding of the overall problem. On occasion, it also helps them find better solutions than originally planned because that overall perspective can help see things during the Sprint that aren’t obvious if looking only at the individual parts.

The Sprint Goal provides focus in Daily Scrum and an opportunity to refocus if the Sprint goes off-track. Finally, jointly identifying and achieving shared goals is a key element for growing a group of people from a working group to a true team.^[2]

How to Make Better Sprint Goals

In my experience, most Sprint Goals are not clear. Some poor examples I’ve seen are:

• Fix 10 bugs
• Finish 7 unrelated User Stories
• Complete the work assigned to the team in JIRA (yes, this is remarkably anti-Agile and ineffective, however, I see it all too often)

None of these examples help focus the Team, nor do they provide clarity on what they’re seeking to achieve.

So, what makes a better Sprint Goal? A good Goal answers questions such as: Why is it worthwhile to undertake this Sprint? Are we attempting to solve a problem? Are we implementing a feature or clarifying an assumption?

Improved versions might include:

• Reduce the shopping cart abandon rate from 50% to 30% by improving usability and performance – Solves a problem. We’re losing sales because we have a poor checkout experience.
• Add filters to the existing product search results so that buyers spend less time finding items that meet their needs – Implements a feature.
• Offer free shipping for orders over $40 – Tests an assumption that free shipping will increase the amount people spend per transaction.

Should the Product Owner set the Sprint Goal? No. It’s good for them to go into Sprint Planning with some business or product objective in mind, but it’s through negotiation with the Development Team that the actual Sprint Goal emerges, as all grow towards a shared understanding of what is desirable and achievable in the Sprint. “Achievable” means possible to accomplish while upholding the quality agreed to in the Definition of “Done.”

Agile Coach Bob Galen suggests that you imagine crafting an email to invite your whole company to your Sprint Review. What will you put in the subject line and first few sentences to entice them to attend?^[3]

That’s your clue for your Sprint Goal – the shared understanding created between the Product Owner and the Development Team of the desired outcome of the Sprint.

[1] “Building a Practically Useful Theory of Goal Setting and Task Motivation A 35-Year Odyssey” and New Developments in Goal Setting and Task Performance, both by Edwin Locke and Gary Latham
[2] “High Performance Teams: What the research says” by David Wilkinson, –The Oxford Review Feb 2019
[3] “Sprint Goals – Are They Important” by Robert Galen