What is Story Mapping Feature Prioritization? Overview, Guide, Examples, and Template

This article is part of the product roadmapping prioritization chapter of our product roadmapping guide. Check out the full Product Roadmapping Guide here.

User story mapping is a powerful way to understand how your customers use your product and what features they need. Here’s everything you need to know to implement story mapping.

You’ve got a massive product backlog and you’re looking for a way to sift through to find what’s important. What do you do?

User story mapping is a tool for organizing your features into meaningful groups based on how your customers actually use your product. It can be powerful and I love how it’s one of the few prioritization frameworks that centres your customers’ experience.

Here’s what it is and everything you need to know about it.

User story mapping (TL;DR)

• User story mapping is a visual and collaborative technique for prioritizing software features popular in agile/scrum frameworks.

• It works by visually organizing features based on your users goals and the way they use your software.

• User story mapping helps product teams understand customer pain points and prioritize features that will improve user experience.

• The downside is that it can be time intensive and may lead you to prioritize features that aren’t necessarily consistent with business needs and objectives.

What is user story mapping?

User mapping, also known as customer journey mapping or experience mapping, is a process of visually representing the steps a user takes when interacting with a product, service, or system. For software product teams, it helps you understand user needs, pain points, and even emotions at each stage of their experience. That helps you design better solutions and optimize the overall customer experience.

Jeff Patton was an early proponent of story mapping (although, as he reminds us, he didn’t create it) because the idea of a “flat” backlog (a backlog where features are ordered by when you’ll build them) didn’t make sense to him. He argues that a flat backlog is missing important context because it’s separated from a larger view of the entire system.

What’s a user story?

User stories are natural language descriptions of features or design elements. They’re written from the perspective of a user. It usually follows the format: "As a [user type], I want to [action], so that [benefit/outcome]."

For example: a user story for an e-commerce website might be: "As a registered customer, I want to add items to my shopping cart, so that I can purchase multiple products at once."

What’s a story map?

Patton’s solution was to organize the features in functional groups based on how customers actually use the software.

Patton’s original method is to write features (in the form of user stories) on index cards or sticky notes and arrange them physically on a surface. The result would be a story map.

This is an example of a story map. It’s divided into activities, steps, and details.

The index cards represent three different elements.

• Activities are major actions that people do with the software. An example activity for accounting software might be “managing sales”. The user story for the activity might be, “As a B2B SaaS company, I want to be able to keep track of our sales transactions and revenue.”

• Steps (also called “tasks”)are the smaller stories tied to the larger activity. For the accounting software, in the “managing sales” activity, some tasks might be “creating invoices”, “recording payments”, and “reminding clients about overdue invoices”. These are also your “epics” if you’re doing agile product development.

• Details (also called “subtasks”) are even smaller pieces within a task. In the accounting software, subtasks of “creating invoice” might be “editing the date”, “adding a price”, “calculating taxes”, and so on. These are also your “stories” if you’re using that terminology as part of an agile development process.

Through the story mapping process, you arrange tasks under activities, and subtasks under those. You also arrange stories (and their relevant tasks and subtasks) along a timeline in the order that a user would usually do them.

The result is a kind of “skeleton” where the top are the major actions your users can do with your product, and hanging from them are the associated tasks and subtasks.

Patton described the resulting user story as a kind of skeleton where the “ribs” (the steps and details) hang off the “backbone” (activities). They’re arranged in the sequence that users perform them.

Together, they make up the entire system that is your products.

How to do user story mapping—a step-by-step guide and example

Story mapping is a valuable technique for visualizing and prioritizing software features based on user goals and experiences. Here's a step-by-step guide to creating a story map.

Note: If you’re doing this activity in person, make sure you have some pieces of large poster paper, markers, some tape, and a bunch of index cards. If you prefer, you can also do this in story mapping software applications, including Savio.

Step 1: Invite your stakeholders

Assemble a diverse group of stakeholders. You want a group of people who are familiar with the users and your software’s functionality. This could include product managers, members of your development teams, designers, and, perhaps even end-users. Having a mix of different people will help ensure a comprehensive understanding of user needs and perspectives.

Aim for between 4 to 8 people.

Tip: You could do this alone, but you might not get the same quality of map or the same team benefits from doing it together.

Step 2: Identify user personas and their goals

Define the different types of users who will interact with your product. Create detailed user personas that outline their needs, goals, and expectations.

Tip: Your marketing teams may be able to help here—they usually maintain a set of customer personas that you can use.

For each persona, list the high-level goals they want to achieve using your product. Break down these goals into smaller activities or tasks users will perform to accomplish their objectives.

Related: The role of Marketing teams in tracking customer requests

Step 3: Identify activities, tasks, and subtasks

Here, you’re essentially identifying what your software does.

You’ll figure out the main activities and their related tasks and subtasks. Write each one on your index cards. Try to frame product features as a user story.

Step 4: Create your user story map

Organize user stories on a two-dimensional map.

How you do this is up to you. I like to make the horizontal axis represent the sequence of user activities, with activities further left coming earlier and activities further right coming later. On the vertical axis, I put the priority levels—tasks and subtasks that are higher up are more important, those lower down are less critical.

I suggest walking through your product as if you were a user. Your team will come in helpful here, helping you remember all the steps and thinking through all the necessary details.

The result should be a physical representation of how customers use your product.

Here’s another example of a user story map. You can see that it becomes a visual representation of how your customers use your product. In this example, features are also prioritized by release, too.

Tip: Again, you can do this on paper, or you can do this using software. In Savio, you can do it using our roadmapping feature.

Step 5: Plan releases

Now you should have your main activities, the steps related to those activities, and the details stacked in order from most important to least important. Next, you plan which are going to make it on this roadmap and which you’re going to save for a future release.

Because details are stack ranked by importance, you can draw horizontal lines across your board to delineate releases. The first, most important features make up your minimum viable product (MVP). The next ones can go in release 2. And so on.

Step 6: Review and adjust

The idea is that your story map becomes a physical artifact like your roadmap. You can put it up on your wall and regularly review it to ensure it remains aligned with changing user needs, business goals, and project constraints.

Then, you can update the map as necessary to reflect new insights and priorities.

When should I use story mapping?

For an MVP: Most people suggest that story mapping is especially useful when you’re trying to figure out what should go into your MVP and what can wait. In other words, very early in your product.

For mature products: However, Patton also suggests that you can do a smaller version of it for planning later releases, too. You can even do it with individual features to figure out the critical details you’ll need for those features. In other words, it can become a tool that helps you design your feature and determine the necessary specifications.

Benefits of the story mapping prioritization framework

User story mapping is a valuable technique for planning and prioritizing software features. Some of its benefits include:

• Customer-centric. By focusing on user goals and experiences, user story mapping helps teams gain a deeper understanding of their target audience and their specific requirements and then building the product to meet those needs.

• Context. Some methods of feature prioritization give you a ranked list of priorities, but they’re disconnected from the larger picture of how your product works. User story mapping helps you see the system as a whole and make priority decisions based on how each piece fits together.

• Improved communication. Visualizing features and their relationships on a user story map helps you communicate clearly about features and ensure everyone is on the same page regarding the product's goals and priorities. It’s collaborative and helps make sure that your team considers multiple perspectives.

• Simplified planning. Breaking down complex new product features into smaller, manageable tasks helps teams plan and estimate work more effectively. User story mapping also facilitates release planning by dividing the story map into multiple iterations based on priority and dependencies.

• Adaptability. Regularly reviewing and updating the user story map ensures it remains aligned with changing user needs, business goals, and project constraints, allowing teams to adapt and respond to new insights and priorities.

Pitfalls of the story mapping framework—and how to avoid them

While user story mapping offers various benefits, there are some potential pitfalls that teams should be aware of.

1. Requires significant user research

The effectiveness of user story mapping depends on a deep understanding of user needs, goals, and how they use your product. In fact, Jeff Patton often talks about using story mapping with his clients in groups that include users. If you don’t do enough user research and don’t include the voice of the customer, you can end up with incorrect assumptions and misaligned priorities.

What to do: Make sure you’re bringing in the voice of your customer. Some ways you can do that include:

• Actually ask users to join you in the mapping process

• Conducting user research to help you understand your customers, what they need, and how they use your product

• Asking a diverse group of your colleagues to join you, including customer-facing team members—customer success, sales, support, and so on.

2. Overemphasis on user perspective

The emphasis on users is a good thing—but it can have some downsides if you’re not careful. By focusing primarily on user goals and experiences, you could inadvertently overlook important technical constraints or business objectives.

For example, this framework may not often result in prioritizing tech debt or strategic features.

What to do: Make room in your development budget for each release to include features that may not be directly tied to activities on your user map, including tech debt.

3. Time investment

Another downside of the user-mapping process is that it can require a significant investment of time by your team—especially if it’s a new process for you.

What to do: You can cut down on the time by working to lay out a clear process before hand, and helping your teams understand what to expect.

What about alternative prioritization frameworks?

Not sold on story mapping? No worries, there are many other potential prioritization frameworks you could use instead. Here are a few of them:

• ICE framework. The ICE scoring method asks product managers to evaluate potential features, initiatives, or ideas on impact, confidence, and ease.

• Value x Effort matrix. A simpler version of ICE that doesn’t consider confidence. I don’t love this one—I think you’re better off using ICE.

• RICE framework. A close cousin of ICE. What makes it different is that in addition to “impact”, you also estimate “reach”. Also, you typically estimate “effort” instead of “ease”, so the formula changes a bit.

• Weighted scoring. Similar to ICE, RICE, and Value vs. Effort, but it’s even more flexible because it lets you include any factors you want.

• The MoSCoW method. This method categorizes features into must-haves, should-haves, could-haves, and won’t-haves. I don't find it super useful, but some people like it.

• The Kano Method. This framework categorizes features into buckets based on how they affect the user experience. I love that it’s customer-centric, but it’s a lot of work to do properly.

• The Savio method. This is the strategy we use. Basically, you track what your customers are asking for and match those requests with their other data (like MRR). Then you can prioritize the features to your roadmap that best meet your specific business goals.

Final takeaways

User story mapping is a powerful and versatile technique that helps teams visualize, prioritize, and plan software features based on user goals and experiences. It’s commonly used by agile teams.

By focusing on the needs of the target audience, user story mapping fosters a shared understanding among stakeholders, improves communication, and enables the efficient allocation of resources for better software development. Just be aware of the pitfalls, and make sure you address them:

• Begin with a solid understanding of your user needs (perhaps even inviting your users to the mapping session)

• Make sure you’re also making room for tech debt and strategic features in your development budget for each product roadmap

• If you haven’t used it before, make sure your team understands what will happen in the mapping session and what to expect

Ultimately, user story mapping allows teams to deliver user-centric products that provide real value, enhancing the overall user experience and driving product success. It can help you focus on the big picture to build the right product.

Want to implement Usermapping? You Try out our (free) template. Or, get started making a user story map on your Savio roadmap.

Still not sure? Fair enough—picking a prioritization framework can be complicated. Take a look at the other models out there, or learn more about how we do it at Savio.

Up next: The 8 Most Common Prioritization Frameworks—and How to Choose One

Additional resources

Customer feedback and feature requests:

• Guide to collecting product feedback and feature requests

• Guide to centralizing feature requests

• Guide to prioritizing feature requests

• Guide to closing the customer feedback loop

Userful product management tools:

• Roadmapping tools

• Top feature request apps

• Top free feature request apps

• Feature voting board tools

• In-app feedback collection tools

(Thanks to the following articles for helping me better understand ICE and giving more context about its strengths, weaknesses, and how to do it well.)

Last Updated: 2023-05-03

Want more articles like this?

Product Leaders from Slack, Zapier, and Appcues read our newsletter to delight customers, lower churn, and grow revenue.

Send me more like this

Unsubscribe anytime.