User Story Map

The living picture of the whole product. A user story map lays out two dimensions: the user journey (left to right) and delivery order (top to bottom). Every story lives at the intersection of where it happens in the journey and when it ships.

The X-axis is the backbone: the activities of the user journey in order. The Y-axis is initiatives: each row is one initiative, labeled with its quarter. Initiatives are the planning unit — each is scoped to one quarter, carries a problem statement, solution statement, release notes draft, release plan, person sprint estimate, feature flag name, and DRI, and delivers through one or more releases within that quarter.

Prefer to learn by example? Case Study: Mapping Antar walks one company through every decision on this page — when one board is right, when to split into several, and the line between an activity, an initiative, and a story.

Terminology

One Story Map Per Track

A user story map is anchored to one track: one coherent end-to-end flow, whose activities form the backbone. A track is usually one persona’s journey, where a single primary persona owns the backbone end to end. It does not have to be. An internal or operational track can be co-owned by several primary personas working the same flow, the way an operations team runs one fulfillment pipeline together. Either way, other actors (secondary personas) step into the track at specific activities and get a persona pill on the stories they touch, not a map of their own.

Board and persona are two different axes, and they answer two different questions. A board asks which journey: it is defined by its backbone, the ordered activities across the top. A persona asks which actor: the primary persona a board is already understood to be for, or a secondary persona stepping into someone else’s journey. Keep the two separate: don’t reach for a new persona pill because you’re unsure whether a new board is warranted, and don’t split into a new board just because a different actor shows up at one activity. The redundancy to watch for is on the persona side: if every story on a board carries a pill for that board’s own primary persona, the pill isn’t adding information, it just repeats what the board already says. Drop it, and keep pills for the secondary actors who actually need one.

A product needs a separate story map only when there is a genuinely different track: a flow whose backbone activities do not belong on any existing one. The strongest signal is a new primary persona who owns a new end-to-end journey, since that is usually what changes the backbone. But a co-owned internal flow (one team, one pipeline) is a single track, not one map per role.

An ecommerce product is a clean example. The customer browsing and buying has a completely different flow from the ops team processing orders or the finance team running reconciliation. Mixing them on one story map produces a backbone that is incoherent for both groups. The customer track has one primary persona; the back-office track has several who co-own it.

Customer Platform — the journey a shopper takes through the product:

Primary persona: Customer. Secondary personas involved at specific activities: CS (Support), Legal (Checkout — consent).

Back Office — the journey internal teams take to run the operation:

Primary personas: Ops, Finance, CS, Legal. No Customer stories live here. Four roles co-own one track, and that is still one board, not four. This is the multi-persona case the persona-per-board rule misses.

A story like “Submit return” (customer initiates a return) belongs on the Customer Platform story map under Support. “Process return” (ops resolves it) belongs on the Back Office story map under Fulfillment. Same real-world event, two different user stories on two different story maps.

A subtler split turns on a different question: who wants a story is often not who is in it. Compliance may require age verification at Checkout, but the story sits at the customer’s Checkout activity with a Customer persona, because that is where the work happens. Compliance’s motive lives in the initiative’s problem statement, not as a persona on the card. If the requirement also needs a control an internal team toggles, that toggle is a second story on the Back Office track: the same Submit return / Process return split. Place a story by where it happens, not by who asked for it.

When to create a new story map: when there is a new track, a coherent flow whose backbone activities fit no existing one. The strongest signal is a new primary persona who owns a new end-to-end journey, since that is usually what changes the backbone. The test is ownership of a flow, not contact with one: an actor who merely touches an existing track (CS at Support, Legal at Checkout) is a secondary persona and gets a pill, not a map. Split only when someone stops participating in a flow and starts owning a different one. Two cautions in the other direction: several roles co-owning one internal flow are still one track, not one map each; and the signs you genuinely have a second track are activities with nothing to do with each other, no coherent left-to-right flow, or rows that always feel out of place.

A board maps to a track, not an account. The most common over-split is one board per partner, client, brand, or segment. Resist it: many partners travelling the same journey are still one board, with the partner as a persona or a feature flag — not a map each. One board per partner quietly turns into one product per partner, and you end up customising instead of unifying. A partner earns a board only when it owns a genuinely different track end to end (e.g. a partner-admin portal), never just because it’s a new logo. Creating a board should be a deliberate, rare act — the default answer to “new board?” is no; it’s usually an initiative, a persona, or a segment.

This is not a task tracker. Story status (To Do / Done) reflects whether a story has shipped — not whether a Jira ticket is in progress. The story map shows the structure of the product, not the state of a sprint. If you find yourself updating stories daily or attaching sub-tasks, you’ve drifted into task management. The map should be stable between quarters; only the initiative detail changes as work progresses.

One Initiative, Several Boards

Not every goal fits inside a single journey. When one genuinely crosses tracks, say a must-have compliance change that touches the Admin, Doctor, and Patient journeys in the same quarter, it does not need to be created three times over. An initiative can be a member of several boards at once: it shares one problem statement, solution statement, release plan, and DRI across all of them, while its stories are placed on each board’s own backbone.

On every board it belongs to, it shows as one linked row, pointing to the other boards it also lives on. On the Q Overview, it appears once, not once per board, since it is one initiative regardless of how many journeys it spans.

This is the mirror image of the over-split covered above: don’t fork an initiative into a copy per board to make it fit one journey when the goal is genuinely one thing playing out across several. Split boards by backbone, let an initiative span boards by problem.

The Story Map

X-axis: backbone activities in user journey order. Y-axis: initiative rows, each labeled with its quarter. Shipped initiatives collapse to a single line. The ecommerce Customer Platform story map — five activities, three initiative themes across three quarters.

Each initiative row shows quarter, status, PS estimate, and DRI. The quarter label is not a divider — multiple initiatives in the same quarter sit as independent rows on the story map.

Initiative Detail

Click any initiative name to open its detail. The Y-axis becomes personas — showing which roles are touched and where in their journey. All initiative fields are in the header. Releases are listed below.

The empty persona rows are meaningful: Cart Enhancement is Customer-only. An initiative that should involve Legal (e.g. a discount mechanic with tax implications) but shows Legal as empty is a gap to catch before shipping.

Horizon View

Groups initiatives by quarter — what is in flight now, what is coming. Used for planning conversations and communicating direction.

Initiatives as the Planning Unit

Planning flows from initiatives. When the product needs to accomplish something new, an initiative is created: scoped to a quarter, sized in person-sprints, gated behind a feature flag, with a clear problem and solution, a DRI who is accountable, a release notes draft that explains the before and after, and a release plan with specific milestones. Every story on the story map belongs to an initiative.

The story map shows what shipped, what is building, and what is planned — across every initiative, across the full user journey. The initiative detail shows the same picture zoomed in: which personas are touched, where in their journey, what the stories are, who owns each one, and where they stand.

Coverage gaps show up in the initiative detail: a persona row that should have stories but is empty, an activity column the initiative should touch but doesn’t. These are worth addressing before the initiative ships.

In Glide: Roadmap Navigation

Roadmap is a single menu item in Glide. Inside it, two things are always visible: the Q Overview and the list of story maps. Story maps can be added and removed as the product evolves.

Roadmap
  ─────────────────────────────────────────────────
  Q Overview              │  [content area]
                          │
  Story Maps              │
  · Customer Platform     │
  · Back Office           │
  + New story map         │

Q Overview is the default landing. It shows all initiatives across all story maps, grouped by quarter. This is the cross-map visibility layer — what’s shipping this quarter, across every journey, in one place. Each initiative row shows its story map, PS, DRI, and milestone progress. Click any initiative to open its detail.

Story maps are listed below Q Overview. Each is one track, one coherent flow. Click a story map to open it — the full X/Y view with initiative rows and activity columns. Managing the story map (adding initiatives, placing stories, editing fields) happens here.

Add/remove story maps from the left panel. A new story map starts with a blank backbone — name the activities that define that journey, then begin placing initiatives.

Quick-add everywhere. Every axis ends in a +: activities at the end of the backbone, initiatives at the bottom of the rows, stories inside any cell, milestones and releases on the initiative page. One click, one input, Enter to add, Enter again for the next one. Creating an initiative never opens a form; details are filled in on its page when they exist.

Guardrail behaviors. Story status cycles on click on the map (to do, in progress, done): one click to update, no dialog. Deleting a release does not delete its stories; they return to the initiative backlog. A backbone activity that still has stories cannot be deleted; move or delete the stories first. Q Overview stays read-only. Clients see the roadmap; only the internal team edits it.

The Q Overview and the story maps are the same data viewed differently. The story map is the working artifact. The Q Overview is the communication layer. Neither is more correct — they answer different questions for different audiences.

Keeping It Alive

• Every story belongs to an initiative. If you cannot assign one, the story is not ready to place.
• Fill initiative fields before placing stories. Quarter, person sprints, feature flag, problem statement, solution statement, DRI, release plan — if these are empty, the initiative is not ready to be worked.
• Assign every story. Unassigned stories are a sign the initiative hasn’t been properly broken down yet.
• Post updates on every active initiative regularly. The DRI writes what moved, what’s blocked, and a confidence call: on track, at risk, or off track. An active initiative with no update in 2 days is stale, and stale is visible. Milestone checkmarks alone hide drift.
• Collapse shipped initiatives. They are accessible via show ↗ but should not dominate the view.
• Update immediately when scope changes. A map two weeks behind reality is worse than no map.

Handling Pivots

A pivot changes what the product is for or who it serves. When that happens, the backbone changes too — and the story map must keep up.

What constitutes a pivot. Renaming a feature is not a pivot. Changing the target persona from shoppers to merchants is. Adding a B2B layer on top of a B2C product is. Spinning a marketplace off into a separate product is. The test: does the X-axis (the backbone activities) need to change to reflect reality? If yes, you are looking at a pivot, not a release.

Three responses, in order of disruption:

Evolve the existing story map. If the backbone activities still hold but their meaning has shifted — the same column now serves a different persona, or an activity has been renamed to reflect a new positioning — evolve in place. Rename columns. Archive old initiatives that no longer apply. Add new ones for the new direction. Preserve the full initiative history in the archive. This is the right move for most pivots: the journey is still recognisable, just refined.

Migrate to a new story map. If the backbone is substantially different but enough carries over to be worth preserving, create a new story map and migrate relevant initiatives. The old story map is archived but remains readable — it is a record of what was built and why. Migrated initiatives carry their original PS, SS, release plan, and release notes forward. The new story map starts with a clean backbone, and migrated initiatives are re-placed at their correct activity columns. Mark migrated initiatives clearly so the history is traceable.

Archive and start fresh. When the pivot is a full discontinuity — a different product category, a fundamentally different user, a different problem space — archive the old story map entirely. The archive is preserved for reference. The new story map starts blank. Trying to carry over initiatives from an unrelated context creates noise, not continuity.

Preserving history. Regardless of which approach is used, no initiative is ever deleted. Archived story maps and collapsed initiatives are the product’s memory. Release notes, problem statements, and milestone records belong there permanently. If a decision from three quarters ago shaped what exists today, the story map should be how you trace it.

When to create a new story map. The trigger is a change in the backbone, not a change in direction. If the activities that define a user’s journey through the product change substantially — new steps, removed steps, a fundamentally different flow — that is when a new story map begins. A new quarter does not warrant a new story map. A new product surface that has a genuinely different journey does.

Next: Discover