Why Flat Backlogs Fail and How to Build Effective User Story Maps

This article is translated from Jeff Patton’s blog “User Story Mapping”, original URL: http://jpattonassociates.com/the-new-backlog/. Because the original blog is long, it has been split into two public‑account articles: I Flat User‑Story Backlog Issues and II How to Build and Use a User Story Map.

Why does a flat user‑story backlog perform poorly? How can we build a better backlog to describe the system more effectively, prioritize, and plan releases?

Gary and I spent an entire day creating a user‑story map—a superior product backlog. Building the map helped us focus on the whole product rather than on individual stories.

When prioritizing, Gary considered the entire system context. His goal was to build a product called Mimi (Music Industry Marketing Interface). While sorting the story “Band members promote a concert”, we realized the story was too large—it was an epic that required many details such as designing a poster, building an email list, mailing the poster, and tracking market response. At the final stage of the map we discovered that building a faster, easier‑to‑use poster‑sending tool was a good idea, which later proved successful.

Mimi was eventually released; it now sends millions of messages each month. Its excellent user experience makes it feel like a piece of art, and the story‑map backlog still lets us view the system from the highest level.

Flat User‑Story Backlogs Are Ineffective

In my experience, one of the most troublesome aspects of agile practice is the flat user‑story backlog—it feels like a clumsy idea. If I want to develop software incrementally on a small scale, I need to know where to start. The backlog orders stories from high to low value, which is useful for a project manager, but I am not a project manager.

I wrote this blog while returning from a client site by plane. Both the client and I felt the user‑story organization and release‑planning process over the past two days went very smoothly. I am pleased to see the client’s strong commitment to the practice, which I call a “user‑story map”. My first article on this practice, “How You Slice It”, was published in January 2005, and I had been using it for many years before that.

Over the years I have grown to love this practice so much that I began to view it as a “silver bullet”, which for me is a warning sign. Yet I see more and more people adopting similar practices, indicating I am not alone in my enthusiasm.

Let me describe what bad user‑story writing looks like, what a user‑story map is, and why it solves the problem.

Flat Backlogs Make It Hard to Explain What the System Does

When stakeholders or users ask, “What is the system you are building supposed to do?”, they are usually handed the flat backlog. I find that simply ordering stories by priority does not help explain the system’s purpose.

Understanding the whole system is the hardest part of software development. A common complaint I hear from agile teams is that they lose the “big picture” of the system, even if they once had a clear view at the start.

I usually explain the problem with flat backlogs using a tree metaphor (see images below). The trunk represents the system’s goal or ideal benefit; large branches represent users; smaller branches and twigs represent user capabilities; and the leaves represent user stories that are small enough to fit into an iteration.

After all work is done and everyone shares a common understanding, I feel like we have plucked all the leaves, put them in a bag, and cut down the tree.

This is my view of a flat backlog: a bag of leaves without any contextual background.

Context is the crucial information that truly helps describe a system.

For a New System, a Flat Backlog Cannot Confirm All Stories Have Been Identified

Holding a stack of index cards or a table filled with user stories, I can spend hours staring at them and then hours discussing them, yet I always have an uneasy feeling that something is missing. I know I cannot capture everything, but I want to feel more confident.

Think about how often, when you are scoping software requirements, you have overlooked important functional modules.

Using a Flat Backlog Makes Release Planning Difficult

In typical projects I have participated in, the number of user stories ranges from a few dozen to over a hundred. Early on I try to keep stories at a high level; even so, a backlog of around 120 stories is normal. Analyzing each story in detail and deciding whether to adopt it is extremely tedious, and prioritization meetings have always been a painful memory for me.

Author Bio

Translation by Li Qiang, senior DevOps consultant, solution architect, and marketing director at LEANSOFT, former Microsoft Visual Studio product senior solution expert, IBM Rational product senior solution expert, HSBC China Software Development Center CMMI consultant, Scrum Master, SAFe, CMMI, PMP, CSQA, etc.

Project experience includes: OPPO agile development platform, ZTE agile development project, YuanGuang software process improvement, Guangfa Bank ALM project, Guangzhou Rural Commercial Bank ALM project, Sichuan Rural Credit ALM project, PICC ALM project.