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 Journey

A user story map is anchored to one user journey, owned by one primary persona — the actor whose end-to-end path is the backbone. Other actors (secondary personas) step into that journey at specific activities; they get a persona pill on the stories they touch, not a map of their own. A product needs a separate story map only when a different primary persona owns a different end-to-end journey.

An ecommerce product is a clean example of this. The customer browsing and buying has a completely different journey 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.

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.

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.

When to create a new story map: when a new primary persona owns a new end-to-end journey — which is what makes the backbone change. The test is ownership, not contact: an actor who merely touches an existing journey (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 journey and starts owning a different one. Signs you’ve got a second primary persona: the activities have nothing to do with each other, you can’t draw one coherent left-to-right flow, or certain rows always feel out of place.

A board maps to a journey, 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 journey 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.

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 user journey. 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 a weekly update on every active initiative. 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 this week 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