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.
🎧 You can listen to the audio version of this article here: https://www.romanpichler.com/podcast/seven-product-backlog-mistakes-to-avoid/
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.)
Read On …
To read the rest of this article and access the remaining tips, please head over to my website: https://www.romanpichler.com/blog/product-backlog-mistakes/
Learn More
You can learn more about effectively working with the product backlog by attending my Product Owner Masterclass and by reading my book Agile Product Management with Scrum.
Source: https://www.romanpichler.com/blog/product-backlog-mistakes/
