User Story Mapping for the Big Picture

The Issue with Flat User Stories

Product Backlogs are often made up of long lists of flat User Stories. While User Stories are great for describing and discussing requirements — gradually building a shared understanding across the team — relying on them alone has a significant drawback: you lose sight of the big picture.

Think about what it’s like to onboard a new team member or walk a stakeholder through the system. Pulling up a list of 50 User Stories and explaining them one by one isn’t just tedious — it obscures how everything fits together. Without structure, the forest gets lost in the trees.

User Story Mapping

To address this, Jeff Patton introduced User Story Mapping — a technique that builds a skeleton for organizing and discussing requirements, so that a shared understanding can emerge.

One common pitfall with User Stories is treating them purely as documents. The word Story exists for a reason: it encourages people to tell the story, sparking discussion and building understanding together. User Story Mapping supports that storytelling. Items of different granularity are displayed on the map simultaneously, letting you walk through the entire system at a high level and zoom into details where needed. Following the natural flow of a narrative, items are arranged sequentially — typically left to right — with larger items broken down into smaller ones directly beneath them.

• Activity: A high-level goal encompassing several related tasks — for example, purchasing from an online store.
• Task: Something a user does to accomplish a goal — for example, reviewing the shopping cart, adjusting quantities, applying coupons, or completing payment. Tasks form the backbone of the map, providing the big picture of the system.
• Subtask: A more granular breakdown of a task — for example, paying by credit card, gift card, or PayPal. Subtasks hang beneath their parent task like ribs, filling in the execution detail.

Remember: the goal isn’t to build a perfect map, but to build shared understanding.

Priority and Release Slices

Since products are typically built incrementally, deciding what to build first matters. Rather than comparing priority across different tasks — which often doesn’t make sense — it’s more meaningful to prioritize subtasks within the same task. For instance, debating whether “review the shopping cart” is more important than “pay for the items” is a false comparison; both are steps in the same checkout flow. It’s far more intuitive to decide that “pay with credit card” should come before “pay with gift card,” since credit card is the dominant payment method.

To visualize releases, slice the map horizontally into lanes using a dividing line — each lane representing a planned release.

The map isn’t set in stone. As you learn more and gather feedback, update it to reflect your evolving understanding.

For a deeper dive, visit Jeff Patton’s site.