Seven Product Backlog Mistakes to Avoid

The product backlog is a simple yet powerful tool to capture and revise detailed product decisions and direct the work of the development team. Unfortunately, effectively using the backlog can be challenging. This article discusses seven common product backlog mistakes to help you recognise and fix them.

The Product Backlog is Too Big

A few years ago, I was asked to help a healthcare company with their agile transition and its impact on product management. One of the challenges the agile transition team was concerned about was the choice of the right product backlog tool, which at first seemed odd to me. But when I was told that the backlog in question had over 40,000 items, I could see that there was an issue.

Admittedly, that’s by far the largest product backlog I have come across to date. But I find it not uncommon to encounter backlogs that range from several hundred to a few thousand items. But such a product backlog is difficult to comprehend, let alone prioritise and update. This is problematic especially for young products and those that experience a bigger change, like a life cycle extension, as their backlogs tend to be volatile and require frequent and sometimes bigger adjustments.

You should therefore strive to keep your product backlog as concise as possible whenever your product faces uncertainty and change—be it market, business, or technology related. The following three techniques will help you with this: First, group related items into themes. Second, keep lower-priority items coarse grained. Third and most importantly, focus the backlog on a specific product goal. Then decline and remove items that do not serve this goal, as I discuss below.

The Product Backlog is Too Detailed

Another time, I was asked to help a team of a major charity in the UK whose task was to create a new website for their fund-raising campaigns. The product owner told me that she’d refined the product backlog as well as she could but that the development team were still not happy with it. Looking at the backlog, I noticed that it contained only detailed user stories—no epics or other coarse-grained items.

But an overly detailed product backlog makes it hard to see the wood for the trees: There is simply too much information. This, in turn, makes it difficult to prioritise and update the artefact. What’s more, it is likely to contain speculative and ultimately wrong items, especially when the development effort is characterised by uncertainty and change.

I therefore recommend that you start with an initial product backlog that is intentionally sketchy and incomplete, especially when your product is young or experiences a bigger change. Then let the backlog evolve based on the feedback received from users, customers, and stakeholders. This allows you to minimise the effort to stock the product backlog and to base your product decisions on empirical evidence, rather than gut-feeling.

The Product Backlog is Not Appropriately Refined

A while back, I was working with a company that connects consumers in the UK with a tradesperson like a plumber or gardener. Back then, the company was still a startup, and the product owner had asked me to help them address a planning issue: The development team routinely overcommitted and never managed complete all the work in a sprint.

When I was shown around the office, I saw some paper cards on the wall with big, sketchy epics on them, and I asked the product owner if these were part of the product backlog. The individual replied, “No, this is the product backlog.” Given that the backlog did not contain any sufficiently refined, ready items I was no longer surprised that the development team struggled to get sprint planning right.

While you don’t want to make your product backlog any more detailed than necessary, you should ensure that its high-priority items are ready. This requires them to fulfil the following three criteria: First, they are sufficiently clear and understood by the development team. Second, they can be completed in a sprint according to the Definition of Done. Third, they can be tested. Getting the high-priority items ready is best done together with (some of) the development team members, as I discuss below.

The Product Backlog is a Wish List

Some product backlogs—like the one with 40,000 items mentioned above—resemble a wish list, a catalogue that contains anything and everything that you might ever need. The trouble with such a backlog is not only that it is usually too big. It also results in a “feature soup,” a product that resembles a loose collection of unrelated features. This leads to a weak value proposition and a poor user experience, which are hardly hallmarks of a great product.

But if these backlogs are so bad, why do they exist? There are two main reasons: First, a lack of strategic alignment and focus, and second, a lack of empowerment. The former means that there is no product goal that guides the decision if an item should be added to the product backlog or not. You might, for example, brainstorm user stories and decide to add all of them. Who knows, they might come in handy at some point in time!

A lack of empowerment causes you, the product owner, to have a hard time declining stakeholders requests and to feel obliged to accommodate them. But if you are not able to say no, your product backlog is in danger of serving individual stakeholders and their personal goals—rather than maximise the value the product creates for the users and the business.

To prevent your product backlog from becoming a wish list, follow these two tips: First, select a product goal and align your product with a strategic plan like a product roadmap (as I discuss below). Second, have the courage to say no. Decline any ideas and requests that are not aligned with the product goal. (See my article Boost Your Product Leadership Power for advice on increasing your authority.)

The Product Backlog is Not Effectively Prioritised

Some time ago, I was working with the product manager of a new healthcare product when I suggested to prioritise its features. The individual looked at me surprised and replied, “I can’t. They are all high-priority.” Prioritisation, of course, requires deciding how important an item is. If everything is high priority, everything is equally important. This means in effect that nothing is a priority. But without clear priorities, the development team lacks direction.

If you struggle to prioritise your product backlog, try the following two measures: First, ensure that the product backlog items serve a specific product goal, as mentioned before. Second, select a small set of practical prioritisation factors. The three factors I like to recommend are risk, cost-benefit, and dependencies.

Here is how you can apply them: Initially prioritise the product backlog by risk and consider user, technology, and business-related risks. Assess all backlog items together with the development team and move those to the top that carry the highest risk. This approach accelerates learning, and it avoids failing late when changing course is more costly. Once you’ve addressed the key risks, order the product backlog by cost-benefit, and move those items to the top that give you the biggest bang for the buck, as the saying goes. Finally, don’t forget to consider dependencies whilst using the other two factors. These include dependencies on individual team members and on other teams, as these can influence the backlog prioritisation.

The Product Backlog is Not Shared

A few years ago, I was working with a group of product owners based in the Netherlands who wanted their development teams to get better at delivering what they asked for. It turned out that the product owners refined the product backlogs and wrote user stories on their own and then handed off the high-priority items to the dev teams who were based in Romania. The teams did their best to correctly interpret the user stories. But more often than not, they got it wrong, as they had little knowledge about the end users and their needs.

While a lack of collaboration in the situation described might be obvious to an outsider, I find it not uncommon that development teams aren’t properly involved in the product backlog work. But refining, prioritising, and updating the backlog should be teamwork, as shown in the picture below. As the product owner, invite the development team members to work with you on the backlog, and expect that they will support you. If that’s not the case, then discuss the issue in the next sprint retrospective.

Collaboratively working on the product backlog and co-creating its items offers the following two benefits: First, it leverages the collective knowledge and creativity of the development team, which usually leads to better backlog items—items that are just as detailed as they have to be. At the same time, it allows you as the person in charge of the product to transfer knowledge about the users and their needs to the dev team.

Second, it makes the team members feel valued and respected. It empowers the individuals and increases their motivation to work on the product. People are no longer handed requirements to be worked on. They now contribute to the product decisions and help shape the solution.

If you don’t regularly work on the product backlog together with at least some of the dev team members, then give it a go. Set up a collaborative workshop, be it onsite or online, and ask your Scrum Master to facilitate. Initially, this might require you to spend more time working on the product backlog. But in the longer run, it should reduce your workload. It might even result in the development team being happy to do some of the refinement work on their own.

The Product Backlog Lacks Strategic Alignment

A common product backlog mistake and a root cause of several mistakes discussed above is a lack of strategic alignment: The backlog is not systematically connected to a strategic plan like a product roadmap. But without strategic guidance and a clear product goal that governs it, the backlog can easily grow too be, become hard to prioritise, and turn into a wish list. This was also the case for the huge product backlog I mentioned earlier: The strategic objective of the product was unclear, and this made it hard to determine which items should be added to the backlog.

I therefore strongly recommend that you connect your product backlog to an actionable product roadmap that states the value the product should create in form of product goals for the next nine to twelve months, as the picture below illustrates. Sample product goals might be acquiring users, increasing conversation, removing technical debt to future-proof the product, and reducing cost.

In the picture above, a goal-oriented, outcome-based product roadmap directs the product backlog. This is done by copying the next product goal from the roadmap into the backlog. The goal then helps determine the items that should be included in the product backlog, that is, only those that help meet it. (You can find out more how to the product roadmap and backlog can complement each other in my article The Product Roadmap and the Product Backlog.)