User Story Mapping Checklist

Before inviting attendees, the product manager writes a one-page brief: who the user is (named persona, not "users"), the outcome the product is meant to drive, and the success metrics. Vague vision = a map that wanders for two hours and produces sticky notes nobody acts on.

At minimum: product owner, tech lead or staff engineer, UX designer. For mature products, add a customer support or CSM rep — they hear the gotchas first. Cap the room at ~8; bigger groups produce shallower maps.

Lay out three horizontal swim lanes: backbone (user activities), tasks (user steps), and stories (slices of work). Use a templated frame from Miro's User Story Mapping library or build in FigJam. For in-person sessions, swap the digital board for a long wall and 4x6 sticky notes — physical maps still beat virtual for kickoffs.

Open with the persona's top-level goal — "the new buyer wants to onboard and run their first import in under 10 minutes." Confirm the slice of journey in scope (acquisition? activation? a specific feature?). Without this fence, the backbone sprawls.

List the 5–9 high-level activities a user performs, left-to-right in chronological order: "Sign up" → "Connect data source" → "Configure import" → "Run import" → "Review results." Keep activities verb-first and persona-perspective, not feature-perspective.

Under each backbone item, drop the discrete tasks the user does. "Connect data source" → choose source type, authenticate, pick tables, validate connection. Keep tasks at user-intent level — not implementation steps like "call OAuth endpoint."

Use the "As a [persona], I want [capability], so that [outcome]" form. Color-code by status (new / refined / ready). Surface alternative paths and error cases below the happy path — Patton's original technique calls these "the underbelly."

Only required when the mapping session ended without MVP consensus. Bring a smaller group — PM, tech lead, designer — and resolve the disagreement before the map ages out. Don't loop the full room back in until the conflict is named.

Tech lead flags stories with hidden complexity: schema migrations, third-party API limits, auth changes. Mark them with a complexity tag (S/M/L/XL) and split any "XL" story before it enters a sprint.

Use Given/When/Then or a checklist of observable outcomes. "User can authenticate via Google SSO" → Given a Google Workspace account, when the user clicks Sign in with Google, then a session is created and the user lands on /onboarding. Stories without testable AC don't enter sprint planning.

One epic per backbone activity, stories under each epic. Link the Miro/FigJam map URL in each epic description so the map stays the source of truth — sticky-note-to-ticket drift is the most common reason mapping sessions feel like wasted effort six weeks later.

Slice 2 and slice 3 sit above the MVP line. Tag each story with its target release (e.g., R1-MVP, R2-Polish, R3-Scale). Sequence by user-value-per-effort, not by what's easiest to build first.

Two weeks after the MVP-slice ships, pull cohort data: activation rate vs. baseline, week-1 retention, drop-off by funnel step. Compare against the KPI targets set in release planning — not against vibes.

Customer success team is closest to the friction. Pull recent ticket themes from Zendesk or Intercom and tag them against the map — surfaced friction usually maps to a specific story or task you skipped or under-scoped.

The map is a living artifact, not a session output. Move shipped stories to a "Released" lane, add new tasks discovered post-launch, and re-prioritize slices 2 and 3 against what you learned. Stale maps get ignored and the team reverts to ticket-by-ticket planning.