Drowning in an Oversized Product Backlog? Story Mapping Is Your Life Raft

Can you guess how many Product Backlog Items (PBIs) are in your Product Backlog right now? I’ll wait while you go look.

“Over 1,000 items in the Product Backlog, for one team,” I heard recently. I was so stunned, I couldn’t respond for a moment. As the story wound on, I heard that their team is having trouble with motivation and engagement. They don’t understand how their day-to-day work ties into the bigger picture. That’s far from surprising. When the Backlog is that big, it’s depressing and feels disconnected from the reality of the work.

The Math Isn’t Mathing

Simple math will illustrate how illogical it is to have a large Product Backlog. The result is bad enough for 100 items in the queue (graveyard?), let alone 1,000.

Let’s create an imaginary team. In fact, to keep this simple, let’s fantasize and make it an impossibly ideal team — they can complete seven User Stories per Sprint, all User Stories are the same size, all Stories meet the Definition of Done, there are no defects in their work, and there is no rework.

These are, of course, best-case assumptions; reality is far worse.

So if our fantasy team has a Product Backlog of 100 items, it will take over 14 Sprints (or 28 weeks, assuming 2-week Sprints) to get through that queue, assuming nothing is added in the meantime. For most teams, that too is a fantasy because the queue grows faster than the team’s work, so our problem is getting worse, especially if the Product Owner doesn’t have the discipline and authority to say No.

That’s using the example of 100 PBI. Remember, this article started after a conversation with someone who had ten times that amount.

28 weeks multiplied by ten = yikes.

Time Isn’t the Only Issue

There are a number of problems that large Product Backlogs cause, as I’ve written about in this article on the Scrum Alliance site. Here are some of the highlights:

• Work queue can’t be properly prioritized
• Important things get lost
• Less important items get worked on simply because they’re near the top
• Morale lowers because there is never a sense of progress
• Team members can’t see how an individual Product Backlog Item or User Story contributes to the long-term goals

Enter Story Mapping

Jeff Patton invented Story Mapping to help a client deal with just such a mess. Jeff and the team printed out the User Stories and started to sort them on the floor, looking for patterns within to try and organize and understand. Organizing the collection into a visual map allowed them to evaluate how the User Stories related to the Product Vision.

How to Use Story Mapping

I’ll use an example of an app I’m currently building to illustrate how to make a Story Map. We’re creating a family expense management app that handles receipts, credit card reconciliation, expense categorization, and more. In the process of building it, the Product Backlog started to be used as a wish list or a graveyard, not as a simple list of upcoming work.

So we created a Story Map, working through these steps:

1. Strip anything related to Technical Debt out the Product Backlog. A simple rule: the Product Owner should understand and prioritize everything in the Product Backlog. Since fixing technical debt is the role of the team and not the PO, it doesn’t belong in the Product Backlog. (See Technical User Stories or The Team Try to Pull a Fast One on the Product Owner
2. Start with the key User or Persona for the Product. In the case of our expense app, the persona is someone who wants to understand where the money is going so they can ensure their daily spending decisions line up with long-term goals (e.g. riding bikes and travel).
3. Take a slice of the Product Backlog - lets say maybe the top 100 items - and select those that are relevant for that persona.
4. User Steps or User Task¹ layer. Group related items, for example:
   • Creating an Account and Profile
   • Upload and Scan Receipts
   • Receipts by email
   • Manual Editing of Receipt Data
   • Upload Credit Card Statements Reconcile Receipts against Credit Card Transactions

5. Activities/Themes layer. Review the Needs or User Tasks and look for relationships between them. In our example:
   • New User
   • Receipt Management
   • Credit Card Reconciliation

6. Repeat for each Persona
7. Walk through the Story Map. Does it tell the story of how the product will be used? If not, we’ve identified a gap. The larger the existing product backlog, the more likely it is to contain gaps of this nature.

If you’re like the person I was talking with and you have over 1000 items in your Product Backlog, it may not be possible to finish this activity in a finite time. My back-of-the-napkin math says 60-100 hours of work to get a rough draft of the Story Map using a Product Backlog of that size. I’ve never seen a team map with more than ~200 items before they’ve done a good enough job to understand the shape of the overall strategy.

This will lead to the next set of shocking suggestions. A Product Backlog with over 1000 items is full of items that will never be built. Some of these items were added to address problems that have already been solved. Other items were added several years ago, and they are no longer relevant. Many were added by stakeholders who no longer work at the organization. Hanging on to these items makes it much more difficult for the Product Owner or the team to see the product that they could build, because their thinking will be anchored by past ideas that are no longer relevant.

Instead of trying to map every item, the backbone (Activities/UserSteps) of the Map serves as a placeholder for items that will be worked on in the future.

Keeping the Map and the Product Backlog Manageable

It is easy to get caught up in creating a Map with all the details worked out, over a year in advance. I’ve seen some Story Maps with over 200 individual User Stories underneath the User Steps and Activities. It looks impressive and well-organized. The problem is that most of it won’t be worked on before the landscape changes.

For the portion of the Map that will be worked on in the next ~3 Sprints, a detailed understanding of the User Stories is good. For areas of the Map that will be worked on over the next few months, go only as far as the User Steps. Beyond that, note only the Activities.

The common refrain is “What if I misplace that gem of an idea?” The answer is that in a backlog of anything larger than 100 items, you already misplaced that gem. The Agile point of view is that —if it really is a gem— we will find it again. Further, the version we wrote down a year ago would restrict us from finding a better solution when we revisit it. That said, many Product Owners take a copy of the mess and archive it somewhere (the freezer?). Fantastic, shoot me an email the day you actually find that in the freezer. I can wait.

Whether you delete or archive the old Product Backlog Items, don’t keep them in the Story Map. Doing so creates a false sense of security that these items will be built in the foreseeable future.

Managing Technical Debt

That first step in building the map caused some heart palpitations. There is a simple approach to managing technical debt. Instead of expecting the Product Owner to prioritize these decisions, the team maintains its own queue and prioritizes them. I recommend using a tax model. For example, “We agree that the average Sprint will pay a 15%-40% tax to pay down the messes in the system.”

In the best case, the team prioritize paying down debt in parts of the system that either:

• Change often or
• Have a Feature that is being worked on in that Sprint

How to decide how much tax to pay? That’s going to depend on the system’s health. Is the codebase healthy? Assume 15% of the team’s time to maintain that. A system that has been worked on for over 5 years and no effort has been made to pay down the debt? Closer to 40%. Even when leaders say, “Don’t waste your time paying down the technical debt, we can’t afford it!! ☠️️💰️💰️”, we still pay the tax. Instead of tidying the mess, we take the time to try to understand the mess before we make the change.²

Unfortunately, as it currently stands, GenAI is making this situation worse, increasing code duplication and other smells faster than they can be fixed.

“The Real Cost of AI-Generated Code: It’s Not All It’s Cracked Up To Be”

Replace Your Product Backlog with a Story Map

A good Story Map is a visual representation of where the Product is going. It helps tie day-to-day work to the Product’s Vision. It gives the Product Owner a clear picture of what will be built over the next few Sprints and months. The Product Owner also gains a tool to discuss with their stakeholders, allowing them to make better tradeoffs on which aspects of the product are prioritized. Using our recommended Portfolio Management approach, the Story Map is a great tool for these meetings to ensure everyone is on the same page. Even if your Product Backlog isn’t an oversized mess, Story Mapping is still an excellent tool.

---

Footnotes

1. Jeff Patton originally called these “User Tasks”. That can be confusing because many developers call much smaller chunks of work “Tasks”. I often use the term “User Step”. Jeff and I are united that Epics are evil. https://jpattonassociates.com/the-new-backlog/ ↩

2. When a codebase is a mess, it takes 124% longer to get a feature built. Worse, uncertainty goes up. As uncertainty increases, predictability decreases. See “Code Red: The Business Impact of Low Code Quality” https://codescene.com/hubfs/web_docs/Business-impact-of-code-quality.pdf ↩