Story Mapping: the flatness problem, solved.

A backlog is a flat list. That is its strength and its disease. Strength: a flat list forces ordering. You pick what's next, and you commit. Disease: a flat list is the wrong shape for the two decisions that matter most at the start of a piece of work, which are what's the user journey and what do we cut to make a smaller first release. A list of three hundred stories sorted by priority hides both of those answers. You read down the list and you see "add forgotten-password flow", "show order history", "filter by category". You have no way to see whether those stories together make a coherent first release, or whether they're three unconnected pieces of three different features that all sound important.

Story mapping, named and popularised by Jeff Patton, is the antidote. It is a two-dimensional view of the same body of work. Across the top: the user journey, left to right, as a sequence of activities the user does. Below each activity: a column of stories that ride that activity. Across the rows: horizontal bands that mark releases. They show what ships first, what ships second, what waits. The artefact answers in one glance the two questions the flat list hides: what's the order, and what can we cut?

The backbone, the slices, the cuts.

The backbone. The top row. A sequence of user activities, left to right, that together describe the complete journey through the product. Discover → Sign up → Configure → Use → Pay. The backbone is written from the user's perspective, not the system's. It lives at activity level, not at feature level. Walking the backbone left to right is a narrative: this is what the user does, in order. If the backbone doesn't read like a story, it's wrong.

The slices. Below each backbone step, a vertical column of stories. Each story is a specific way the user can complete that activity. Under "Sign up" you might have: email signup, social login, SSO, magic link. Some of these are bigger than others; some are nice-to-haves. Stack them roughly by priority, top to bottom. The taller the column, the more depth the team has imagined for that step in the journey.

The release cuts. Horizontal bands across all the columns. A release isn't "the next ten items off the top of the backlog". It's a horizontal cut across every backbone step. The first release is the thinnest possible slice through the whole journey: landing page, email signup, basic profile, core action, Stripe checkout. Five stories. That's a coherent first release because the user can actually do something end-to-end. A deep tower under "Configure" that doesn't connect to "Use" or "Pay" isn't a release. It's a feature without a customer.

Walking the backbone is the journey.

This is the part teams who've only seen story maps in screenshots tend to miss. The backbone is not a list of feature areas or product modules. It is the user's activities in time order, told as a narrative. "First the user discovers us. Then they sign up. Then they configure their team. Then they use the product. Then they pay." If you cannot walk your story map left to right and tell a coherent five-sentence story about what your user does, the backbone has been written from the wrong end, usually the system's end.

The test: read the backbone out loud. Does it sound like a user's day? Or does it sound like a sitemap? If it sounds like a sitemap, rewrite it. The point of the artefact is to keep the team's centre of gravity on the user's experience, not the product's internal architecture.

Cutting horizontally is the release.

This is the second insight, and it's the one that separates story mapping from any other prioritisation exercise. Releases are horizontal cuts, not vertical depth. The MVP is the thinnest possible horizontal slice across every backbone step. The user can complete the full journey, even if every step is supported by the minimum viable story.

The temptation, always, is to go deep on one column first because that column is the favourite, usually "Use", because that's where the product team has spent most of their imagining. Going deep on Use without thin slices through Discover, Sign up, Configure and Pay produces a product that nobody can get into or get out of. Story mapping exists, more than anything else, to prevent that exact mistake.

Where it shines.

• New products. Greenfield work where the team is trying to define an MVP and there's no existing backlog. Story mapping is the single best technique for shaping the first release.
• Big initiatives inside existing products. A multi-quarter feature push: "build the partner programme", "ship the mobile app", "replatform the checkout". Story mapping turns the initiative into a sequence of thin releases, each delivering end-to-end value.
• Replatforming or migration. When the team has to move an existing journey from one system to another, the backbone gives a non-negotiable definition of what "feature parity" actually means, journey step by journey step.
• Stakeholder alignment. Story maps are the most stakeholder-friendly product artefact ever invented. A non-technical exec can look at a story map and immediately understand what shipping first means.

When it's overkill.

Story mapping is heavy. For small features and small backlogs it's the wrong tool. If the entire body of work fits on a flat list of fifteen items, mapping it adds ceremony without insight. The signal that story mapping is worth doing: there are more than thirty stories under discussion, the team disagrees about what the MVP should contain, and there's more than one stakeholder with an opinion about what ships first. Below that bar, save the half-day and just sequence the list.

How to run the workshop.

A first-pass story map takes a half day with the right people in the room. The right people are: the PM (the one who knows the user), the PO (the one who'll own the slices into stories), one or two engineers (the ones who'll tell you when a story is bigger than it looks), design (the surface), and at least one stakeholder who'll have to defend the release scope upstream. More than eight people in the room and it stops being a workshop and starts being a presentation.

The order: build the backbone first, before any stories. Get the user journey onto five to seven cards across the top and argue about only that until it reads like a narrative. Then add slices column by column. What specific ways could the user do this activity? Generate liberally; cull later. Then, and only then, cut releases: start with Release 1, the thinnest slice, and force yourselves to keep it small. Release 2 should be twice the size; Release 3 is a parking lot for "maybe later". If Release 1 contains more than one item per backbone column, cut harder.

On tools: paper still beats Miro for the first pass. Sticky notes on a wall force people to stand up, move things physically, and argue with their hands. Once the map exists, transfer it to Mural or Miro for distribution and updating. Doing the first pass in software flattens the conversation and produces tidier-looking but worse-thought maps.

How we use story mapping at Product Pieces.

Story mapping is one of the two artefacts we build during a Discovery Set Piece, alongside a problem statement. We use it when a client brings us a new product to shape, a big initiative to slice, or an existing roadmap whose phasing isn't holding together. The map produces three outputs: a defensible MVP definition, a sequenced release plan, and a refined backlog that maps directly back into the team's tool of choice.

The artefact stays alive after the workshop. We pin the map in the team's wiki, and we revisit it every quarter. Sometimes the backbone changes, more often the slices and the release cuts move. The flat backlog updates from the map, never the other way round. N°34 · The Backlog is where the day-to-day lives; the story map is where the shape lives.

Next issue: N°08 — UX. The whole thing, not just the screens.