Story map

1. User: who will be using your system (think role rather than person).
2. The user’s goals: what the user is trying to achieve—this is optional.
3. Journey/activities: the steps the user must take to achieve their goal.
4. Tasks/features: the features a system might have to enable the user to complete the activity.
5. Stories: the developable pieces of work that help to create features in the system.
6. Releases: a shippable set of features (think MVP and future updates).

A Story Map documents an entire software system’s functionality. It connects all the different elements of the system focusing on the users of the system. It plots the connections between the user, what they are trying to achieve, the steps involved, the features of a system that enable those steps, and the development work that creates those features.

In essence, Story Maps help teams ensure they are building something worthwhile by ensuring that they never lose sight of the user journey.

Often large and complex, a Story Map is used to scope a project, prioritise features, estimate development work, and plan releases. Along the way, they help identify gaps and build a shared understanding of the system.

• When starting a new project. Use a Story Map when you have high-level requirements and need to break them down into developable chunks.
• When planning a sensible Minimum Viable Product (MVP) release, Story Maps make prioritisation of features easy!

1. Start with your primary user. Write the name of your primary user on a card and put it at the top left of your board.
2. Define your user’s primary goal. Add a card directly under the first card labelled with the first thing a user is trying to do (i.e., a goal). Keep this high level and short!
3. Build your activity layer. Starting under your first goal, add a card for each activity your user does when they are completing the goal.
4. Narrative test! You should be able to read across the activity layer and provide a short, but vaguely sensible, narrative. If you can’t, then you’re missing something or your activities are out of order. Rework as necessary.
5. Zoom out. Back on the goal layer, add more cards to the right to capture any other goals your user has. For each of these goals you’ve added, repeat the above steps.
6. Now that you have a backbone of activities (the what), switch focus to the system features (the how). With your team, brainstorm all the features that would contribute to that activity and list them under the relevant activity.
7. Prioritise. Reorder each feature list by importance, from highest to lowest.
8. Build your development branches. For each activity, add cards to the right that capture the development work involved in delivering that feature. You’ll need your technical peeps here!
9. Next user please! Repeat the whole process with your other users (e.g., admins, editors, superusers, etc.) until you have your entire system mapped.
10. Optional: Slice your map into releases. Use the vertical space to organise your features and development work into releases.

• Work left to right. Work with the story and keep your map in rough time order. This makes it much easier to identify gaps.

• Start with the user. Work down from the user to their goals, then end with features and stories.
• Colour-code the different elements of your map. For example, goals are green, tasks are blue, etc. Be consistent. This makes it easier to follow along.
• Stay focused. Try to complete at least a draft of each layer before moving onto the next.

• Listen to the story. Try asking your users to talk you through a typical day, then use their narrative to capture the relevant activities on the map.
• Document your key (the legend) where everyone can see it! This makes it easy to stick to it.
• Make sure you have enough time and space! Small, cramped rooms and short timeframes mean you will struggle to get value from your efforts.
• Don’t chase the perfect pattern. No two projects are the same and no two Story Maps are the same.
• If you have them, you can use personas to prioritise your features (e.g., “what is more important to this person, feature A or feature B?"")
• Build your enhancement backlog. Capture both features that are absolutely required and features that would make activities smoother or nicer. This will help your team plan a truly viable product.
• Plan your releases. Story Maps can also be used as a visual release planning method if you’re already underway on a project.
• Remember: you don’t need all the peeps all the time. For big stakeholder groups, split them into small groups and follow a validate/add cycle with each group. Each will be able to validate the work of previous groups, identify gaps, and add their own knowledge.

• Not having all the stakeholders involved. Each stakeholder not involved in building the Story Map represents a potential loss of perspective or knowledge and buy-in.
• Personas as your base. If you cut your map by personas—rather than broad user roles—you’ll end up with feature duplication in your map and a prioritisation nightmare! Instead, use your personas to validate your activities and prioritise your features.
• Solo mapping. Just don’t.
• Unnecessarily complex. Not every system is large enough to warrant all five levels of the map. Sometimes simply user → activity → story is enough!
• Not having an agreed upon key (i.e., legend). You need all the help you can get to remember what the difference is between the green and the yellow cards!

• User story: describe user requirements by why, not what.
• Acceptance criteria: define a feature in yes or no terms.

• User story mapping by Jeff Patton