Story mapping as a team exercise

This is a guide to running a story mapping session with your team and building a story map from scratch. It covers who to invite, what to write on the cards, and how to know when you are done. If you have not seen a story map before, read what story mapping is first. The method follows Jeff Patton’s book User Story Mapping. If you are mapping by yourself to understand a product or a problem, try the story mapping solo exercise instead.

Before You Start

A little preparation makes the session go better.

Who to Invite

Invite three to six people. A smaller group misses things, and a larger one slows the session down. Try to have one person from each of these groups:

• Someone who owns the product decision. Usually a product manager. They decide when the group cannot agree on priority.
• Someone who will build it. An engineer who can say “that step is really three steps” or “that card is a week of work.”
• Someone who knows the user. A designer, researcher, or support person who has watched real people use the product.

If you can only get one of these, get the person who knows the user. Without them, the map is a list of features.

What You Need

On a wall: sticky notes in two or three colors, and thick markers so people can read the cards from a distance. On a screen: a tool that lets you put cards in columns and rows and move them around. Cartographer is built for this, but any tool that lets you drag cards will work.

Set aside two to three hours for the first session. You will not finish. A map that is mostly done after one group session is more useful than one that one person has polished for a week.

Step 1: Frame the Problem

Before anyone writes a card, write three things at the top of the wall where everyone can see them:

1. Who is the user? Be specific. Not “customers” but “a warehouse supervisor doing the Monday morning stock check.” If you have personas, pick one. If there is more than one important user, pick the main one for this map and write down the others. You can add them later.
2. What are they trying to do? The result they want, in their own words. “Know what to reorder before the truck arrives,” not “use the inventory module.”
3. Why are we mapping this now? Are you planning a new product, redesigning an existing flow, or looking for the smallest first release? The answer changes how much detail you need.

This takes ten minutes and saves a lot of confusion later. When the group disagrees about where a card goes, it is usually because they are thinking of different users.

Step 2: Map the Backbone

Now tell the user’s story. Start from the moment they first need something and ask what they do next. Write each big activity on a card and put the cards in a row, left to right, in the order they happen. These cards are the activities, the top row of the map. Cartographer calls them journeys.

Some rules for activities:

• Name each one with a verb and an object. “Find a product,” “Check out,” “Track my order.”
• Keep them at the level a user would use to describe the task to a friend. “I looked around, added a few things, and paid.” Those are your activities.
• Expect four to ten. Fewer than four usually means you are mapping a feature, not a journey. More than ten means some of them are steps.
• Include what happens before and after your product. If the user starts by getting an email from their boss and ends by filing a report, those are part of the story even if you do not build software for them.

When you are done, read the row out loud. It should sound like a story. If it does not, change the order until it does.

Step 3: Break Activities into Steps

Under each activity, add the steps the user takes. This is the second row. “Check out” becomes “Review cart,” “Enter shipping address,” “Choose delivery speed,” “Pay,” “See confirmation.”

Steps stay in one row, left to right. Activities and steps together are the backbone of the map. Every later discussion about scope, priority, or releases will refer to this backbone, so take the time to get it right.

Two things to watch for:

• Do not describe solutions yet. “Enter shipping address” is a step. “Autocomplete address field” is a detail that belongs in the next row. Steps say what the user does, not how your product helps them do it.
• Do not skip steps because they seem obvious. “Log in” is boring, but many users get stuck there.

If the group starts debating whether something is an activity or a step, do not spend long on it. Pick one, move on, and change it later if it causes problems.

Step 4: Fill in the Details

Under each step, add a card for everything that might be needed to support it. Different kinds of card are useful here, so mark them differently:

• Stories and tasks. Things you might build. “Save address for next time,” “Validate postcode,” “Show estimated delivery date.”
• Variations. Different ways the same step can happen. Paying with a card or with a saved wallet. Shipping to home or to a pickup point.
• Pain points. Where users struggle today. These come from research, support tickets, or watching people use the product.
• Questions and risks. Things you do not know yet. “Do international users need a different address format?” “Can our payment provider handle this volume?”

This part of the session is noisy. Have everyone write cards at the same time instead of taking turns. Then place them on the wall together and remove duplicates. Do not judge ideas as they go up. The goal is to get everything out of people’s heads and onto the wall where the group can see it.

Keep card text short. A card is a reminder to have a conversation. “Address autocomplete” is enough. If someone needs more detail, they can ask the person who wrote it.

Watch for steps with very few cards. If one step has two cards and the others have fifteen, find out whether that step is simple or nobody in the room understands it.

Step 5: Prioritize Top to Bottom

Within each step, sort the detail cards so the most important one is at the top and the least important is at the bottom.

Do not ask “is this important?” Everything feels important. Ask instead: “If we shipped without this, could the user still get through this step?” If yes, move the card down. If no, keep it near the top.

Some tips:

• Prioritize within each column, not across the whole map. Comparing a checkout card with a search card does not make sense. Comparing two checkout cards is easy.
• Let the person who owns the product decision make the final call, but ask them to explain why out loud. The reasons are often more useful than the order itself.
• Questions and risks usually go near the top. An open question about a step is usually more urgent than a nice-to-have feature for it.

Step 6: Slice a Walking Skeleton

Now draw a horizontal line across the whole map, just below the top one or two cards in each column. Everything above the line is the first release. Everything below it comes later.

Patton calls this first slice a walking skeleton, a term he borrowed from Alistair Cockburn. It is the smallest version of the product that still lets the user get from the start of the journey to the end. It is not polished and it does not handle every case, but it works end to end.

Teams want to make the first slice thick in the areas they are excited about and thin everywhere else, but a first release with a great checkout and no way to find products is not a release.

Once the first slice is drawn, draw a second line for the next slice, then a third. Give each slice a name that says what the user can do after it ships that they could not do before: “First order,” “Repeat orders,” “Orders for a team.” In Cartographer, slices are milestones, and you move cards between them by dragging.

You now have a story map. Read it one more time, left to right along the top slice, and check that it tells a complete story. If it does, the first session is finished.

A Worked Example

Say you are building an app for a neighborhood tool library, where members borrow drills, ladders, and pressure washers instead of buying them. The user is a member who needs a tool for a weekend project. Their goal is to have the right tool in hand on Saturday morning.

Backbone. The activities, left to right, might be: Figure out what I need, Find it, Reserve it, Pick it up, Use it, Return it. Under “Reserve it” the steps might be: Check availability for my dates, Confirm the reservation, Get a reminder.

Details under “Check availability.” Cards might include: see a calendar of when the tool is free, see how many of that tool exist, join a waitlist if it is booked, see suggested alternatives, and a question card: “Do members care about specific brands or just the tool type?”

Prioritized. “See when the tool is free” goes to the top. You cannot reserve without it. The waitlist and alternatives are useful, but a member can get through the step without them, so they move down. The brand question goes near the top because the answer changes how the calendar should work.

Walking skeleton. Browse a list of tools, see if one is free this weekend, reserve it, get a confirmation email, collect it, and bring it back. It skips search, waitlists, reminders, and late fees. A member can complete the whole journey, and the team can find out whether anyone reserves online before building the rest.

Common Mistakes

• Mapping features instead of the user’s journey. If your top row says “Dashboard, Settings, Reports, Admin,” you have drawn a site map, not a story map. Start again from what the user is trying to do.
• Mapping alone and calling it done. A map built by one person only shows what that person knows. Mapping on your own is useful for understanding a problem (see the solo exercise), but the team still needs to see it and argue with it.
• Going deep before going wide. If you add twenty detail cards under the first step before the backbone is finished, you end up with a detailed map of the wrong thing. Do the backbone first.
• Writing cards nobody else can read. A card with tiny handwriting, internal jargon, acronyms, or half a thought only makes sense to the person who wrote it, and it will not last the week.
• Slicing by team instead of by journey. “Release one is everything the backend team can do” gives you a release that no user can use. Slices cut across the whole map.
• Treating the map as finished. The map needs to keep changing as work ships and priorities shift. See below.

Keeping the Map Alive

The first session gives you a map. Some ways teams keep it current:

• Plan from the map. When you plan a sprint or a cycle, take work from the current slice instead of from a separate backlog. If the map and the backlog disagree, trust the map and update the backlog.
• Put research on it. When an interview or a support ticket teaches you something, add it as a card under the step it relates to. The team then sees what you learned next to the cards for that step. See an example of doing this with an AI assistant.
• Mark progress on it. As cards ship, mark them done. When the top slice is mostly done and the second slice is in progress, anyone can see where the product is without a status meeting.
• Re-slice when you learn something. If the walking skeleton ships and users do not behave the way you expected, change the next slice.

Build It in Cartographer

Everything in this guide maps to a Cartographer project: activities are journeys, steps are steps, and detail cards are story cards, with types for questions, risks, pain points, and opportunities. Slices are milestones. Drag cards to change priority, attach personas to keep the user in view, and set status as work ships.

If you would rather describe the map than draw it, connect Claude or ChatGPT through the MCP server and describe your user and their journey. The assistant will draft the backbone and details for you to rearrange. Either way, create a free account and run your first session this week.