The Ultimate Guide to User Story Mapping [2024 Guide]
Whether you’re planning your first user story mapping session or you’ve got a few under your belt, it can be a little overwhelming 🤯
- What’s the process?
- Who do I need to get involved?
- Why are we even bothering with this when we have a perfectly good backlog? (Okay… it might be slightly dysfunctional, but you know...)
- Why are there sticky notes EVERYWHERE?
Most product managers and Agile teams could benefit from a deeper understanding of user story mapping so they can create a more customer-centered view of the work that needs to be done.
Plus, over the last 15 years (since user story maps started to become a thing thanks to Jeff Patton), some of the processes and terms have evolved and there are new tools and apps that can make your life a whooooole lot easier.
We’ve put together this ultimate guide with all the info you need to get up to speed on the latest user story mapping definitions, techniques, and tools. Let’s start with some basics 👇
What is user story mapping?
Here’s a super simple user story mapping definition:
User story mapping is a visualization of the journey a customer takes with a product, from beginning to end. It includes all the tasks they’d typically complete as part of that journey.
To expand on that, user story mapping takes all your user stories (across all your persona types) and assigns them to epics in the order that delivers the most value to the customer. From there, stories are prioritized and mapped to releases.
“User story mapping is a facilitated, curated conversation that brings everyone along for the journey. It’s an opportunity for the product manager to brain dump their insights (who is deep in this stuff day in, day out) and get it into the minds of the team who are about to deliver on it.”
Nicholas Muldoon, Co-Founder @Easy Agile
What isn’t user story mapping?
While user story mapping might have a few things in common with other methods, it’s not the same as journey mapping or event storming.
User story mapping vs journey mapping
Journey mapping is a UX tool that helps teams visualize the journey a customer needs to take so they can accomplish a goal. Journey maps focus on the journey for a single persona or customer, based on the persona’s specific scenario and expectations. This is useful for aligning the team, getting them focused on the user experience, and basing decisions. Unlike user story mapping, it’s focused on the user experience and the vision for the product.
User story mapping vs event storming
Event storming involves running a workshop with key business stakeholders present. The attendees write down business events (things that happen), commands (things that trigger the events), and reactions (things that happen as a result) on sticky notes. These notes are organized sequentially to map out the business processes. Unlike user story mapping, which is focused on refining the backlog to deliver a working product for the user, event storming is more high-level and done early in the product planning process.
User story mapping for agile teams
User story maps can be useful for all agile teams, whether they’re full SAFe or Kanban, but especially if they’re working on a complex product.
User story mapping is a useful technique for agile software development teams because it can help your team deliver working software and espond to change.
This fits right in with the Agile Manifesto.
And let’s not forget the number one agile principle:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
User story mapping puts the focus on the user, ensuring that the backlog contains stories that add real value to the customer by helping them achieve their goals. Plus, story mapping allows your team to plan and order their work so that it delivers the highest value to customers first.
Moreover, because Agile is all about embracing and reacting to change over following a concrete plan, story maps better facilitate efficient adaptation. It’s far easier to swap out sticky notes than it is to revise hefty requirements documents. This flexibility ensures that your team can swiftly adjust priorities and modify plans as new information or changes arise, maintaining alignment with Agile principles.
The anatomy of a user story map
User stories, epics, the backbone and story mapping - oh my! To break down the steps and processes involved in user story mapping down further, let’s define some of its moving parts.
User stories
A user story is a goal, from the user or customer’s perspective. It’s an outcome they want. It’s also the smallest unit of work in an agile framework with the purpose of articulating how a piece of work will deliver value back to the customer.
User stories usually follow the structure:
As a [persona type], I want to [action] so that [benefit].
For example:
Tip: it’s a good idea to focus on just one type of user/persona during your user story mapping session. If it’s your first session, choose your most ideal customer type and write our user stories that will deliver value to them. You can always come back to your other users in future.
Read ➡️ How to write good user stories in agile software development.
Epics
Stories can be associated with epics.
Epics have different meanings depending on who you talk to. But for the sake of this article, we’ll define epics as bigger, overarching stories or steps in the journey that contain user stories. An epic on its own isn’t small enough to become a work item or development task, but the stories it contains probably are.
For example, the epic “Sign up” might contain the following user stories:
- As a customer, I want to read the privacy policy before I sign up for my account so I can decide whether I trust the company with my details
- As a customer, I want to see a list of features and benefits on the sign-up page to remind me about what I’m signing up for
- As a customer, I want to sign up for an account using my Facebook login so I don’t have to remember my username or password
- As a customer, I want to sign up for an account using my email address so I can control access to my information
- And in this example, the next epic might be “Set up and customize my profile”.
The backbone
The backbone is the top row of your user story map. It outlines the essential capabilities the system needs to have.
Your backbone should show the customer journey or process from beginning to end, including all the high level activities the customer will complete while using your product. Depending on how you use your backbone and story map, it could be made up of epics.
The backbone is critical because it gives your team the “why” behind the journey, even if they’re just focused on a single step. It takes away ambiguity around what might lead up to that step and what might follow it, which gives important context for creating a smooth customer journey.
More on: The Anatomy of a User Story Map
Why do user story mapping?
The purpose of user story mapping is to make sure you understand the problem the customer has, and then find a solution to that problem.
You’ll know the answer to:
- Why are we building this?
- Who are we building this for?
- What value will it provide them?
- When do we expect to deliver this?
This will help align your teams, groom the backlog, and more quickly deliver a product that your customers want and need.
John Walpole explains the value of user stories beautifully:
“[There’s] one technique and tool which time and time again I’ve gone back to when I felt like a project maybe isn’t thoroughly understood by the team, or I’m worried that we’re going to end up shipping software that isn’t going to delight customers. This is my go-to technique. I believe it’s going to help you ship software that will delight your customers.”
Without user story mapping, there’s a much greater chance that your team will come up with complicated, non-customer-focused solutions to a problem.
User story mapping helps ensure the team is aligned around what problem the customer has, and how you, as a team, are going to try and solve that problem.
It will keep you focused on delivering the highest impact and greatest value pieces first, enabling you to iterate based on feedback.
Read ➡️ Why User Story Mapping
Benefits of user story mapping
“User story mapping is the best technique I’ve come across to gain shared understanding within an agile team. Alex Hennecke at Atlassian talked about being able to see the forest - instead of just the trees, right in front of him.”
Nicholas Muldoon, Co-Founder @Easy Agile
User-story maps are powerful tools in product development, particularly when it comes to identifying and managing risky assumptions.
Visualizing risk
User-story maps provide a visual framework that highlights potential risks. By mapping out user stories with sticky notes or digital alternatives, it's easy to pinpoint areas where assumptions might not align with real user data or technical feasibility. This visualization helps teams identify elements that could derail a project’s timeline or budget.
Prioritization and resource allocation
Once risky assumptions are identified, user-story maps allow teams to reorganize priorities effectively. Risky elements can be moved to a lower priority, ensuring that resources are allocated to ideas that offer high value with minimized risk. This strategy ensures that projects remain on track, focusing on what's realistically achievable.
Encouraging lean alternatives
Story maps encourage teams to explore lean alternatives first. By testing simpler ideas with similar value propositions, teams can validate concepts without significant investment. This approach allows for learning and iterating, reducing the likelihood of costly failures later in the development process.
Fostering collaborative problem-solving
The process of creating and updating a user-story map is inherently collaborative. It invites diverse team members to contribute insights, leading to more comprehensive risk identification and resolution strategies. By pooling knowledge, teams are better equipped to address assumptions that might otherwise go unnoticed.
Incorporating these practices into your product development cycle can help mitigate risks early, ensuring a smoother path from inception to launch.
There are so many other benefits to user story mapping too, like:
- Plan better - Seeing the user journey mapped out makes it easier for teams to see the big picture of your product and identify any risks, dependencies, and blocks ahead of time
- Greater empathy - It forces your team to see the product from your users’ perspective
- More value sooner - Frequently delivering new value to users is easier when you can order the stories based on value and map them to iterations or releases
- Realistic requirements - By breaking user stories down and visually mapping them, it’s easier to estimate work and see how all the pieces fit together
- Better cross-functional collaboration - With all the upcoming work mapped out, marketing, sales, and other teams can see when you expect to ship new features and updates so they can adjust their marketing communications and sales conversations (without asking you for daily updates)
User story mapping helps your team understand the bigger picture, the why, and the end-to-end customer journey before they dive into the what and how.
Read ➡️ Understand what your customers want with agile user story maps.
The flat backlog vs user story mapping
Before we had user story mapping, we had the flat backlog. Actually, a lot of agile teams still use the flat backlog (no judgement if this is you!). So, let’s talk about what that looks like and how user story mapping has improved this practice.
Read ➡️ DEEP: The 4 Characteristics of a Good Product Backlog
What’s a flat backlog?
Essentially, it’s a to-do list. It includes all the items your team needs to do so they can provide value to your customers, ordered from most valuable to least valuable to the customer. The backlog may be split into current and future sprints to show what outputs are likely to be delivered when.
But I like our backlog!
A simple to do list might be fine if your product is simple, your team is small, and your to-do list is very short. But most products are complex, with multiple teams working on it. And most of the time, the backlog is massive (and constantly growing and changing).
Flat backlogs are complex at scale
If you’ve got hundreds of issues (or more), a flat backlog makes it impossible to see the big picture and surrounding context - which your team needs in order to refine the backlog, find dependencies, and prioritize the work into releases. It can also get pretty overwhelming!
- Specific challenges of using the flat backlog include:
- Arranging user stories in the order you’ll build them doesn’t help you explain to others what the system does
- It provides no context or ‘big picture’ around the work a team is doing
- For a new system, the flat backlog is poor at helping you determine if you’ve identified all the stories
- Release planning is difficult with a flat backlog - how do you prioritize what to build first when you’ve got an endless list?
- It’s virtually impossible to discover the ‘backbone’ of your product
User story maps were designed to overcome these challenges and restructure the backlog to add context, make it easier to prioritize, and put the focus on the customers’ needs. It introduces the X axis, with the backbone at the top to show the customer journey, and the user stories below.
When you go from a flat backlog to multiple axes, your team (and the rest of your organization) can understand what value we intend to deliver to the customer and when.
Read ➡️ The difference between a flat product backlog and a user story map.
When is user story mapping done?
So, when do you actually run a user story mapping session?
Generally, a team will collaboratively create a story map at the start of a project or product. It might be an entirely new product, or the product manager might want to pursue a new idea or feature as part of an existing product.
This involves getting subject matter experts and team members together to run a session where you look at your personas and overarching customer journey, then brainstorm ways you can provide the most value to customers. Then you’ll write user stories for each of your persona types and each step of the journey, based on their needs.
As we’ve already mentioned, it’s best to focus on one persona type per story mapping session to avoid confusion. So, start with the persona who is the best fit for your product or likely represent the largest chunk of your audience first.
Overall, the process could take several days or even several weeks, depending on the complexity of your product (and therefore, the number of steps in the customer journey) and the number of personas.
Getting the most out of User Story Mapping
Who should participate in user story mapping?
Some folks you might invite to your user story mapping party session include your:
- Subject matter experts (whether product owner, product manager, customer support team member, or someone else who interacts with the customer)
- Business owner
- Developers
- Testers
- Marketer
- UX designer
- Facilitator or Scrum Master (it’s useful if you can get another product manager to facilitate the session)
Tip: Try to keep your numbers below 10 participants. Diverse perspectives are useful, but any more than that and it can get tricky to manage and get input from everyone. All the people present should be able to contribute insights into the personas/product/business, or help estimate how long tasks will take to complete.
Mapping the user stories
Once the backbone is established (and your team agrees on the order), you can put the flesh on it. Under each item in the backbone, go the user stories (steps, processes, and details) that support that activity. This involves some brainstorming and creative thinking.
Encourage your team to imagine the different options available to the user, how they might want to experience each step in the backbone, and actions they might take. It can't hurt to do a paper prototyping session alongside your user story map to mock up ideas as you go. Or perhaps that step will come later, depending on the scenario and maturity of your team.
Sequencing
Then you can put your user stories in a sequence to deliver maximum value to the customer as quickly and consistently as possible. So, put the most important user stories at the top, and the least important ones at the bottom.
Cut lines or swimlanes
Your team will get together and discuss and estimate the work involved in each user story. After that, you can add cut lines (usually sprint or version lines) to mark out what your team will deliver and when. At this point, you might shuffle some stories around if it makes sense for the user to get them in the same release.
Read ➡️ Anatomy of an agile user story map.
Tips for successful user story mapping
Involve the right people
It can be tricky to get your team and stakeholders together. They’re busy and probably have a plate full of commitments. But it’s always worth getting everyone to set aside time and step away from the keyboard. User story mapping is important - and you’ll need input from everyone so you can:
- Brainstorm stories then prioritize and estimate them
- Get your team to commit to implementing them
Break it up
“Typically, I’d run these things to try and get as much of the planning, personas, and backbone done on day one as possible. By that point, most people are tapped out because the cognitive load is high. Then the team can go away and sleep on it. Once they’ve had time to reflect on it, they’ll come back with other ideas for user stories and thoughts about how they’d do the work before they start sequencing.”
Nicholas Muldoon, Co-Founder @Easy Agile
You don’t have to do your whole user story mapping session in one go. Depending on the size, complexity, and phase of your product, you might not be able to fit it into one day, either.
Instead, break your session up into 2-3 hour chunks and do it over several days. You might do the first session in the afternoon and the next session the following morning. This comes with a few advantages:
- It means you don’t have to get your stakeholders and teams together for an extended period
- You might find it’s a lot easier to coordinate your calendars when you split your sessions up
- It gives your team time to reflect on the initial story map (they’ll probably think of a million new things to add on day two)
- Your team can get lunch after the session is done and debrief over food and drinks 🍻🍔🍕
A single facilitator
While you DO want all your team and stakeholders at your user story mapping session, you don’t want everybody driving the discussion (too many chefs in the kitchen = not a good idea). Instead choose one person to facilitate the session. Sometimes it even works better if you can choose a product manager from another team to run things.
No phones/laptops
For in-person user story mapping sessions, only your designated facilitator is allowed their device. To avoid distractions, ask folks to leave their phones and laptops in a stack at the door. That way, your team can be fully present for all discussions.
Start with data and evidence
Before you get stuck into user story mapping, bring in relevant data and supporting evidence. All of that is great context for what's to come. And of course, you can’t do user story mapping without a clear understanding of who your users are - and what their goals, objectives, problems, and needs are.
So, create your personas before you build out your customer journeys. That way, you’ll understand how your users will engage with the product, and you’ll be able to write user stories that more accurately reflect reality.
User Story Mapping Approaches
User story mapping example
Let’s go through an example of user story mapping to help you visualize the process for your own product.
- Identify product/outcome
In this example, our product is a free online educational kids game. The outcome is for the user to find and play the game.
- List high level activities (in chronological order):
- Navigate to games website
- Log into account (or sign up if a first-time user)
- Search for game
- Choose game
- Play game
- Share with a friend or on social media
- List user stories under each activity
For example, searching for a game could include the following options:
- Free text search - As a parent, I want to search for a specific keyword so I can quickly navigate to a game
- Browse by category: age group - As a parent, I want to find an age appropriate game that my kids will easily pick up
- Browse by category: type of education - As a parent, I want to find a game that will help my child improve their knowledge and skills in a specific area
- Browse by category: game type - As a parent, I want to find a new game that’s similar to one my child already likes
- Order by top rated - As a parent, I want to find a game that’s likely to keep my kid engaged for a while so I can get some work done
- Order by newest/oldest - As a parent, I want to help my child find a game they haven’t already played, to give them a new experience
- Order by most popular - As a parent, I want to help my child find and play the most popular games
- Order stories from most to least valuable to users
Value is identified from analytics on usage patterns, customer interviews, and other insights.
Your team might check feedback forms to see what parents’ top requested features are, and prioritize these first. That way, they’ll deliver more value, more quickly.
Sequence the work so you know what to deliver and when
Your team will estimate the work involved in each user story and decide what stories you can complete for upcoming sprints or releases. They may group stories that are needed to deliver an MVP, or stories that need to get released together - for example, all the “browse by category” features might go live at the same time.
Split it up over releases or sprints
The team sets your cut lines (for the sprint or version), allowing them to distinguish what they think they can deliver in that sprint/version. This will be based on their capacity and what they need to deliver to users for a minimum viable product (MVP).
A user story mapping… story
During his time at Twitter, our Co-Founder, Nicholas Muldoon, facilitated a session for another team whose goal was to figure out how they should fix an issue with the app. This example (in Nick’s words) shows another interesting application of user story mapping, including the types of issues you might work through and how you can hone in on a particular persona or subsection of your audience.
Step 1: Kick off
We started by getting everyone in the room. Attendees included several subject matter experts - not just the immediate team who were working on the project. This included someone from the user authentication team and a UX designer who had worked on password resets in the past.
The product manager kicked off the session by explaining the situation: “A whole chunk of users are having trouble getting into the app because they can’t remember their password. But in order to get them to go through the tedious password reset process, we want to give them value first to show that it’s worth doing. How?”
Step 2: Persona identification
To figure out the next steps and do user story mapping, we needed to narrow down the audience so we could use it as a framing reference or persona. After all, we were looking at a huge audience of 30 million people, not a single persona.
So we asked: who are we not targeting? Then we were able to take out any pro users and government users, which brought the audience size down to 28 million.
Next we asked: what’s the easiest place to experiment and test this? At the time, there was a feature we couldn’t access on IOS, so we went with Android. Plus, we had great relationships with the US-based phone carrier, AT&T. So we looked at our audience of Android users on AT&T in the US, which left us with a much more reasonable audience size of 3 million people.
We used this persona to experiment with this particular feature without touching all the different use cases.
Step 3: The big steps
Once we’d outlined the persona we were going to focus on, we could talk about what’s in or what’s out. So, we talked about the big steps, like:
- They’re on the Android home screen
- They open up the app
- They see all the features
- They attempt an action (Tweet, like, or retweet)
- They perform a password reset
- These customer-facing epics form the backbone of the user story map.
Plus, in this session, we also included technical epics for stuff we needed from other teams at Twitter. For example, this team didn’t control all the authentication, so they added a technical epic to have a conversation with another team to get that piece on their backlog so they had everything they needed for the experiment.
Step 4: The stories
As we fleshed out the epics, we built out the user stories below each of them.
Step 5: Cut lines
Typically, your team would do estimation and cut lines at this point, but we didn’t need to because timing was less relevant. We had to include all the essential stories to successfully run the experiment.
We did our user story mapping physically on a whiteboard, so we used tape to separate what was in and out of sprint one, two, and three. We had the backlog on the right hand side, which consisted of anything we’d discussed that we couldn’t include this time, but we wanted to come back to later. Maybe some items weren’t applicable to this persona, or we’d come back to it for IOS.
In other scenarios, we’d order the stories based on what we understood would provide the most value, estimate with story points, and then plan the capacity for a week or fortnight of work, based on historical velocity. Then we’d sequence the stories into sprint and versions. Sequencing might involve moving up something of lower customer value because you can fit it in. You might also need to break down a bigger or riskier story and split it into two user stories.
Throughout the process, everyone had the opportunity to voice their opinions (there’s nothing more frustrating than not being heard or listened to) and we’d put it on the board. One of my roles as the facilitator was to manage everyone in the room - from the quietest person to the most outgoing person.
If someone was being quiet, I’d pull them into the discussion and ask them for their thoughts directly. It’s important to pull in from different participants to get a holistic vision or understanding. Because at the end of the day, the purpose of user story mapping is to get the team on the same page. If the team sets off and they haven’t bought into the vision, they’ll soon find that everyone has a different understanding of what’s meant to happen. It’s less about the process, and much more about the alignment of the team.
Results 🏆
As a result of this user story mapping process, the project took a new direction where the app would use the device identifier along with the username to figure out who the user was before they log in. This would allow them to get straight into the timeline so they can get value.
But if they wanted to complete any actions (like Tweet, RT, or like a Tweet), they’d need to put in a password (and would hopefully be engaged enough to complete the process). Overall, it was a very successful user story mapping session!
Physical vs digital user story mapping
So, now that you know the steps in user story mapping, how do you actually implement them?
Traditionally, user story mapping is done physically. You get your team in a room, write out the backbone and user stories on post-it notes, arrange them on a wall, and use a string to represent the cut lines or swimlanes.
It might look a bit like this:
But this process does come with some challenges:
- You’ll have to find and book a room for a day (or longer if you need to map a complex product and user journey)
- We all know that post-it notes have a tendency to lose their stickiness and fall off the wall (even if you totally nail your peeling technique)
- Even if you involve remote team members using video conferencing, it’s tricky for them to read post-its - and of course, much harder for them to contribute
- A team member will still need to enter all the data into Jira once your user story mapping session is done (it’ll look like the below screenshot, which doesn’t resemble your physical story map too much)
“When I worked at Twitter, they tried to do physical user story mapping over video conferencing to include distributed team members. It was challenging. There’d be a lot of ‘Hey Nick, what does this say?’ and I’d need to read it out or type it out on chat.”
Nicholas Muldoon, Co-Founder @Easy Agile
That’s why it’s often better to use a tool or app to do your user story mapping digitally.
While there are a couple of user story mapping apps and software options, the most efficient approach is to use a user mapping tool that integrates directly with Jira.
That way, you don’t have to transfer your work into Jira - your team can move straight into working on their top priority stories as soon as you wrap up your mapping session.
Read ➡️ User Story Mapping for Remote Teams
Jira + Easy Agile TeamRhythm
Jira on its own doesn’t allow you to do user story mapping. It doesn’t replicate the physical session with sticky notes and an X axis. The best it can do is a flat backlog - and hopefully by now, you know that’s not good enough for most teams.
Fortunately, you can run a digital and collaborative story mapping session right inside Jira with Easy Agile TeamRhythm, which is an add-on for Jira.
Here’s how it works:
Add user story mapping capabilities to Jira
Add Easy Agile TeamRhythm to your Jira account. You can get started with a free 30-day trial.
If you open TeamRhythm from an agile board that’s already in use, it’ll automatically get populated with your board’s data, with current issues added to the backlog panel in the right hand panel. But don’t worry - you can easily edit this data. And if it’s a new agile board, you can easily add your backbone, stories, and swimlanes from scratch.
Set up your backbone
Across the top of the board you’ll create a horizontal row of epics (if you already have epics associated with your board, this will be pre-populated). Each epic represents an activity of the users flow through the product. This is often referred to as the 'backbone' of the story map.
These epics can be dragged and dropped and the order of the epics will be reflected on the backlog using Jira ranking.
Creating new epics right inside the story map is simple with Easy Agile. Simply click the “Create Epic” button in the top right of the screen. Add the name and description, then click “Create”. Scroll to the far right of your story map to find your new epic.
Don’t worry about getting everything perfect right away. You have the ability to edit them in-line later.
Add the flesh (or stories!)
Beneath each epic on the backbone, you’ll see any linked User Stories that are ordered by rank. To add a new story, hover over the space where you want to create your story and click “new”. Enter the name of your story and select your issue type from the drop-down (e.g. task, story, or bug). You can also access the Backlog panel to add existing stories or issues - simply click “existing”, search for your issue, and add it.
You can also drag issues in from the backlog panel.
And just like epics, you can edit your stories in-line by clicking on the name of the issue.
Order your epics and stories
Now, put your epics and stories in order. Your epics should reflect your customer’s journey from beginning to end. And your stories should be ordered by the value they deliver to customers.
In Easy Agile apps, you can click and drag to rearrange your stories and epics. And if you move an epic, the associated stories underneath will move with it.
Estimate work
Hover over the estimate field (the gray number on the bottom of each story item). Click to add or edit story points.
Read ➡️ Agile Estimation Techniques
Add and arrange swimlanes (version/sprint)
Now it’s time to decide what issues your team will tackle when by horizontally slicing up the work. Click on the swimlanes button in the top right. You can choose to sequence work by sprints or versions (depending on whether you’re Scrum or Kanban*). Your sprints or versions will appear in chronological order on the story map, and there’s an “add sprint” button at the bottom of the story map where your team can add additional sprints and versions.
* With Kanban, you’d typically sequence work into versions, as there is no sprint. This can help your team whittle down the long list of stories into the 'now' and 'future' buckets.
You can easily drag and drop stories, mapping them to the appropriate swimlane.
Check team velocity to avoid over committing your team during each sprint or version. Hover over the “Not started”, “In progress”, and “Done” indicators on the far right of the sprint or version swimlane to see how your story points are tracking across all the stories and issues. If you have too many story points, you can move some stories to the next sprint or version.
Read ➡️ Agile Story Points: Measure Effort Like a Pro
Try out different views
You can search or create a Quick Filter based on a text search (e.g. contains "As a parent"). Or if you’re using our other product, Easy Agile Personas, we have a tutorial on how you can create a Quick Filter by persona. That way, you can refine your story map and narrow in on what’s really important to you.
Get to work!
All changes made inside the story mapping session are automatically reflected in Jira, so your team can leave the story mapping session ready to start their work.
Get started with Easy Agile TeamRhythm
Easy Agile TeamRhythm works out of the box with your existing backlog (so getting started is super quick and simple). But it gives you that extra dimension to help bring your backlog to life. It’s aliiiiive!
Want to check it out for yourself? We have two options:
Easy Agile TeamRhythm Free Trial
OR play around with our demo (no installation or sign-up needed) :-)
But don’t just listen to us. Here’s what some of our customers have to say:
Jira software is great for following activities and backlogs, but it’s easy to lose the vision of your product without user story mapping. Easy Agile User Story Mapping allows the teams to communicate - not only about activity but also the vision of the product. Some of our teams regularly refer to this tool for retrospectives, and it helps them make the product their product.
- Paul Flye Sainte Marie, Agile and Tools Referent @Kering
We’ve found that Easy Agile User Story Maps brings the team together in one room. As a result, we find ourselves mapping more as a group, which creates a common understanding. Since using the add-on, we’ve been able to speed up planning and more efficiently conduct large story mapping exercises.
- Mike Doolittle, Product Director @Priceline
Since using Easy Agile User Story Maps, we’ve improved our communication and team alignment, which has helped give us faster results.
- Casey Flynn, Distribution Forecast Analyst @adidas
Easy Agile User Story Maps has helped us visualize our workload and goals, as well as speed up our meetings. We love the simplicity!
- Rafal Zydek, Atlassian Jira and Confluence Expert Administrator @ING Tech Poland
See what all the fuss is about
Start your free 30 day trial
Psst: It’s the fastest growing and highest-rated story mapping app for Jira! You’re going to love it.
6 ways to keep your story map alive
Speaking of bringing things to life, we’ve got a few final tips...
Your user story map is designed to be a living, breathing thing so that it can help your team continuously deliver value to your customers. But you’ll miss out on these benefits if your team doesn't continually use it, reflect on it, and refine it.
Here are 6 ways you can keep your backlog alive:
1. Progress tracking
As your team delivers releases, they can visually track their progress against the user story map. With Easy Agile User Story Maps, updates in Jira are reflected directly in the user story map so you can check what percentage of work has been completed. This enables you to identify problems early on and adjust your team’s workload (and future versions/sprints) if needed.
2. Backlog grooming
The purpose of backlog grooming is to maintain a healthy, up-to-date product backlog, ready for efficient sprint planning. A few days before your sprint planning meeting, your product manager will:
- Delete user stories that aren’t relevant anymore
- Create new user stories as needs become clearer
- Assign and correct estimates
- Split user stories that are too big
- Rewrite stories to make them clearer
- Ensure stories are ordered by priority
- Make sure stories at the top are ready to be delivered
It’s much easier to do this using Easy Agile User Story Maps (rather than a flat backlog) because your product manager and team can see all the contextual information. They can shuffle the order around by clicking and dragging, and can quickly update issues with in-line editing.
3. Sprint/release planning
Sprint planning is done at the beginning of every sprint. It’s designed to help your team agree on a goal for the next sprint and the set of backlog items that will help them achieve it. This involves prioritizing backlog items (this should be straightforward, thanks to backlog grooming) and agreeing on what items your team has capacity for during the sprint. Sprint planning sessions tend to run a lot more smoothly when you refer to your user story map. With Easy Agile User Story Maps, you can update your story map with backlog items as you go, and all your changes are reflected in Jira so your team can start work on the sprint straight away.
4. Sprint reviews
At the end of each sprint, your team will do a sprint review to see whether the goal was achieved and that your increment led to a working, shippable product release. Your product manager will look at the “Done” items from the backlog, and the development team will demonstrate the work they’ve done.
The team talks about what went well, any problems, and how they were solved or could be solved. They review the timeline, budget, and potential capabilities for the next planned product release, which puts the gears into motion for the next backlog grooming and sprint planning session.
In Easy Agile User Story Maps, you can easily filter your view to show “done” issues, see sprint statistics, and update story point estimates. That way, you can do a quick and collaborative sprint review meeting, right inside Jira.
5. Roadmaps
You can use your story map to communicate your roadmap with stakeholders and share the product vision. With your upcoming releases and sprints mapped out, it’s easy to see which parts of the customer journey are going to see an update or improvement, and when.
6. Retrospectives
Retrospectives are often held at the end of your sprint or release. Or you might hold them after an event, presentation, every month, or every quarter. Retros are used to help your team reflect on what’s gone well, what could have gone better, and what they’d do differently next time. Your user story map can give your team a visual point of reference during retrospectives, and help them stay focused on the user.
How to learn more about user story mapping
We’re almost at the end, but don’t stop here! There’s so much more to learn if you want to go deeper with user story mapping.
Here are some resources worth looking into:
User story mapping books
Jeff Patton wrote THE book on user story mapping, called User Story Mapping: Discover the Whole Story, Build the Right Product. Jeff was the original user story mapper - at least, he’s credited with inventing the concept and practice.
User story mapping articles
Here are some articles written by us over the last few years:
Story maps - A visual tool for customer focused development (this one has a great video)
How to write good user stories in agile software development
The difference between a flat product backlog and a user story map
Anatomy of an agile user story map
That’s it! You’ve finished the user story mapping ultimate guide! 👏
You have all the tools and info you need to…
- Run your first user story mapping session
- Do story mapping more effectively (and confidently)
- Get more from your story map
- Prioritize your work to deliver maximum value to customers, as quickly and as often as possible
- Work more collaboratively
- Accurately schedule your work
- Understand the why behind the work
Go forth and story map! And let us know how you go.
If you have any questions about user story maps, we’d love to hear from you. You can contact us or send us a tweet @EasyAgile. We’ll update this guide as we come across more user story mapping tips, techniques, and frequently asked questions.
Related Articles
- Workflow
Online user story mapping for remote teams
Get ready for remote user story mapping.
Whether you've done user story mapping before (in person) or you're new to user story mapping, there's a very good chance that you'll need to do remote user story mapping for the first time in 2020.
Even before the pandemic, 4.7 million people in the US worked remote, and an estimated 31% of US workers employed in March 2020 were working from home by April 2020.
And after lockdown ends, it’s likely we’ll see permanent changes to the way we work. Surveys show that 80% of employees are keen to work from home at least some of the time. Plus, more organizations are realizing that offering flexible, remote work options can lead to better work-life balance for employees, lower overheads, lower environmental impacts, and improved productivity....which is all to say that remote user story mapping is about to be the norm.
So, what do you need to know before you run your first online user story mapping event? Let's go through 8 things you should consider for successful remote user story mapping.
1. Get the basics right
First thing's first: you need your basics sorted. Make sure your team understands what user story mapping is, why user story mapping is important, and how to do it.
This will help get them onboard - which is critical, because you'll need them to commit two full days to the process.If anyone on your team is new to user story mapping, send them to our user story mapping ultimate guide. It's got everything they need to know 👌
2. Set your agenda
User story mapping should be a scheduled event. You should know what's happening and when to make sure that your team stays on schedule and completes all the steps required to produce a finished story map. Here's a fairly standard agenda:
Knowing your agenda is especially important for remote story mapping, because it's a lot easier to veer off track when people aren't physically in the room.
Sally might head to the kitchen for a long lunch and miss the most important bit. Or Bob might need to coordinate his schedule so that his partner can mind the kids for a solid hour or so while he's involved in estimating the work.Setting the agenda ahead of time will also help your team start thinking about the session and user stories before the event. That way, they’ll feel more prepared and ready to participate in discussions.
By the way, if you’re not familiar with all the items in the above agenda, we talk more about the specific steps and how to do user story mapping in our ultimate guide to user story mapping.
3. Plan your session
When are you going to hold your live online user story mapping session? Most teams need a full two days to work through all the steps, so you'll need to find two days (ideally in a row) when everyone is available.
If your team is located across multiple time zones, you'll also need to consider what times give you the best crossover so that team members aren't working at 2 am (unless they want to).
4. Decide on who
Remote user story mapping could present you with a bit of a conundrum. Unlike in-person events where you're limited on space, you could technically have unlimited people chime into your virtual session. But you definitely don't want that - too many people will make you inefficient (and they could use their time to add value to your business in other ways).
It’s a good idea to cap your numbers at around 12 people. Include team members and stakeholders across multiple departments, along with your product manager, UX designer, and developers.
Also decide who is going to lead the session and who will be responsible for creating the story map.The good news is that online user story mapping makes it easy to record sessions - you'll have a digital record of your conference calls and your story mapping board. So anyone who's curious can easily catch up on the highlights once your event is over.
5. Make some rules
Working and collaborating remotely can feel a bit like the wild, wild west - especially the first few weeks or months. Everyone's still figuring out how to make this thing work - and how to get things done effectively in a new environment.
We've all been to conference calls where somebody didn't know proper etiquette or their audio/video ended up distracting other attendees.
So, with that in mind, here are some rules you might like to share ahead of your remote user story mapping session to make it a little less chaotic and a lot more productive:
- Don’t be late
- Put your camera on
- Save your food for a designated break
- Don’t take your device for a walk
- Close your door, if you can
- Stay focused on the task (no checking emails!)
- One person talks at a time
- Wait until everyone has had a chance to provide input before moving on
- If you’re not talking or participating in the conversion, mute yourself (to avoid interference or background noise that could stop people from focusing)
Of course, be realistic. Your team members are likely working from home in less-than-ideal circumstances, whether they're quarantined with family members, stuck at home with a sick child, or dealing with a bad-mannered house dog.
There will be noise and disruptions - and despite their best efforts, someone will be late. As long as people do their best to hit the mute button at the right time and consider others, your session should run smoothly.6. Get your tech ready
Previously, you might have been able to show up to a user story mapping session with just your brainy self and a pen 🧠🖊️ You'll still need your brain for remote user story mapping, but you can ditch the pen.
Instead, you'll need to make sure you and your team have access to the technology they need to participate and collaborate online. Things like:- Zoom, Google Hangouts, or Skype access - Everyone should have their account ready to go, along with some experience using the platform
- Slack or Microsoft Teams - Set up real-time chat for when you’re not in a video conferencing session
- Headphones & Microphone - These should be working well and tested ahead of time
- Webcam - While not strictly necessary, a webcam will help you replicate the feeling of being in the room together
- Internet - Ask your team to test their connection and make sure it's reliable - and ideally, have at least one backup option (like a local cafe, friend's house, or mobile hotspotting)
The right technology will allow you to adapt the user story mapping process to work for your remote team.7. Get user story mapping software
A physical user story mapping session usually involves a long sheet of paper or cardboard, with hundreds of tiny post-it notes for each story and backbone item, and string to show cut lines.
The good news is, if you're doing remote user story mapping, you won't need to clear out your nearest stationery supply store 🎉 But you will need to equip yourself with some digital tools to replicate the physical story mapping board online.
There are a few user story mapping tools on the market, but we're partial to Easy Agile User Story Maps. It plugs straight into your existing Jira workspace, allowing you to:
- Visually map your customer journey
- Assign stories to epics
- Prioritize and sequence stories
- Arrange stories into sprint and version swimlanes
- Add story point estimates
It’s just like physical user story mapping, but done digitally inside of Jira. That makes it perfect for running a remote user story mapping session.
Okay, so we may be a little biased, but these people aren't:
Want to give it a spin for your upcoming remote user story mapping session? Sign up for our free 30-day trial to see the benefits for you and your team. We’re confident you’ll love what you find!8. Integrate your workflow
Last but not least, make sure that your remote user story mapping session integrates with your workflow
Good news! If you use a digital user story mapping tool (like Easy Agile's), you'll find it much easier to integrate your story map into your workflow. Once your user story mapping session is finished, your user stories are already set up in Jira, and organized into sprints or versions so that your team knows exactly what they need to work on next.
(Although they might want to take a day or two to ease back into it...😴)
Set yourself up for success!
With the right preparation and tools, you'll set yourself up for a relatively smooth remote user story mapping session. And after that? You'll be set to do your future story mapping events in a more streamlined, digital way, whether you're required to work remotely, collaborate with a distributed team, or work from the office.
And based on the way work is changing in 2020 (and beyond), that's a very good skill to have.
- Workflow
How to use story points for agile estimation
Story points can be a little confusing and are often misunderstood. Story points are an important part of user story mapping, and many agile teams use them when planning their work. But they aren't as simple as adding numbers to tasks or estimating how long a job will take.
Even if you’ve been using story points for a while, you’ll find that different teams and organizations will use them differently.
So, let’s define story points, discuss why they’re so useful for agile teams, and talk about some of the different ways teams implement them in story mapping and sprint planning.
What are user story points?
Story points are a useful unit of measurement in agile, and an important part of the user story mapping process. You assign a number to each user story to estimate the total effort required to bring a feature or function to life.
When to estimate story points
User stories can be estimated during user story mapping, backlog refinement, or during sprint planning.
Once a user story has been defined, mapped to the backbone, and prioritized, it's time to estimate the story points. It is a good idea to work with your team to do this, as each team member plays a different role in different stories, and knows the work involved in UX, design, development, testing, and launching. Collaborating on story point estimation will also help you spot dependencies early.It is best to assign story points to each user story before you sequence them into releases or sprints. This allows you to assess the complexity, effort, and uncertainty of each user story in comparison to others on their backlog, and to make informed decisions about the work you decide to commit to each sprint or release.
How to estimate user story points
When estimating story points, you're looking at the total effort involved in making that feature or functionality live so that it can deliver value to the customer. Your team will need to discuss questions like:
- How complex is the work?
- How much work is needed?
- What are the technical abilities of the team?
- What are the risks?
- What parts are we unsure about?
- What do we need in place before we can start or finish?
- What could go wrong?
Tip: If you're having trouble estimating a story or the scope of work is overwhelming, you might need to break your story down into smaller parts to make multiple user stories.
What is a story point worth?
This is where story points can get a little confusing, as story points don’t have a set universal value. You kind of have to figure out what they’re worth to you and your team (yep, real deep and meaningful stuff).
Here’s how it works:
- Each story is assigned a certain number of story points
- Points will mean different things to different teams or organizations
- 1 story point for your team might not equal the same amount of effort involved in 1 story point for another team
- The amount of effort involved in 1 story point should remain stable for your team each sprint and it should remain stable from one story to another
- 2 story points should equal double the effort compared to 1 story point
- 3 story points should equal triple the effort compared to 1 story point… and so on
The number you assign doesn't matter - what matters is the ratio. The story points should help you demonstrate relative effort between each story and each sprint.
Estimating story points for the first time
Because story points are relative, you need to give yourself some baseline estimates for the first time you do story point estimation. This will give you a frame of reference for all future stories.
Start by choosing stories of several different sizes:
- One very small story
- One medium sized story
- One big story
...a bit like t-shirt sizes.
Then assign points to each of these baseline stories. Your smallest story might be 1. If your medium story requires 3 times more effort, then it should be 3. If your big story requires 10 times the effort, it should be 10. These numbers will depend on the type of stories your team normally works on, so your baseline story numbers might look different to these.
The important thing is that you’ll be able to use these baseline stories to estimate all your future stories by comparing the relative amount of effort involved.
Over time, you and your team will find estimating user stories becomes easier as your shared understanding of the work develops. This is where story points become most valuable, helping your team align expectations and plan more effectively.
Make estimation easier
An app for Jira like Easy Agile TeamRhythm makes it easy to see team commitment for each sprint or version, with estimate totals on each swimlane.
Using the Fibonacci sequence for story point estimation
Some teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.) for their story point estimates, rather than staying linear or allowing teams to use any number (1, 2, 3, 4, 5, 6, 7, etc.).
This has its benefits. For example, if you're looking at a story and trying to estimate whether it's a 5, 8, or 13, it's much quicker and easier to come up with an answer than trying to land on the right number between, say, 4-15. You'll likely reach a consensus much more quickly.
This also means you won't be able to average the team's story points to finalize the estimation. Instead, you'll need to discuss the work and decide on the best estimate from a limited set of options.
But it does limit your options - if you have a story that’s more effort than 34, but less than 55, your estimate might be less accurate.
Using story points to estimate velocity
After some time working together most teams will have a good idea about how much effort is involved in each story point.
Of course, timing isn't exact - there's a bell curve, and story points are designed to be an estimate of effort, not time.
But story points (and knowing their approximate timing) can be useful when it comes to figuring out how much your team can get done each sprint.
You should be able to estimate about as many story points your team can manage during a two-week sprint, or whatever timeframe you’re working to.
For example, if your team can usually get through 3 story points per day, this might add up to 30 story points across a two-week sprint. This is your velocity.Velocity is useful for user story mapping and sprint planning. When mapping your user stories to sprints or versions, you can check the total story points and make sure it matches up with your velocity so you’re not over- or under-committed.
As you can see there are a few different methods for estimating work. The best advice is to be conservative and not overload the team.
Over time, your estimations should become more accurate.Using Story Points in Scrum, Kanban, and Extreme Programming
Story points are central to estimation and planning processes in many agile methodologies. Scrum and Extreme Programming (XP) rely heavily on story points to gauge the effort and complexity of user stories.
Scrum teams use story points during sprint planning to decide which tasks to include in the upcoming sprint, encouraging discussion that leads to shared context and understanding of the work.
Extreme Programming on the other hand, uses story points to assess the size of features, enabling teams to prioritize and allocate resources effectively. Teams using Kanban can benefit from story points by using them to set work-in-progress limits and optimize the flow of tasks across the board.
While the specific practices may differ, story points can help encourage team collaboration and a more predictable flow of work.
- Workflow
The Difference Between a Flat Product Backlog and a User Story Map
It’s one of the most common practices in agile software development; the flat product backlog. We’ve all seen them, we’ve all contributed to them, and we’ve all inevitably drowned in them.
In its simplest form, a flat product backlog is a laundry list of ‘stuff to do’ that will ultimately provide value to the customer. These actionable items are prioritised (top to bottom) in the order the value will be delivered. If a team is adopting the Scrum method the backlog is split into future sprints to provide an indication of what will be delivered and when.
Depending on the size and requirements of the organisation, the list of things to be done could be 10, 100 or 1,000 actionable items. It’s easy to see how managing the latter comes with the challenges of updating, assigning, grooming and scheduling these items.
What’s Wrong With Flat User Story Backlogs?
So far we know that flat backlogs represent a list of things to be done. This comes with its challenges, and its shortcomings were best described by Jeff Patton when he said;
We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.
After all that work, after establishing all that shared understanding, I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree.
That’s what a flat backlog is to me. A bag of context-free mulchHow do you pick an item from a list, and deem it the thing that’s going to provide the most value to your customers, without that additional context?
Shortcomings of a Flat Product Backlog
- The flat backlog makes it impossible to discover the ‘backbone’ of your product — the customers interaction experience with the product
- Arranging user stories in the order they’ll be delivered doesn’t help a product manager explain to others what the system does
- The flat backlog provides no context or ‘big picture’ around the work a team is doing
- A flat backlog makes it hard for the product manager to determine if they’ve identified the relevant user stories
- Release planning is difficult with a flat backlog. How do you prioritise what to build first in an endless laundry list?
User Story Maps
A story map is a visual representation of the journey a customer takes with a product, including the activities and tasks they complete. This visualisation helps the team to focus development on providing the most value to customers and their desired outcomes.
It provides context for teams by answering the following questions:
- Why are we building this?
- Who are we building this for?
- What value will the solution provide for the customer and when?
The story map still showcases the ‘stuff to be done’, the difference here though, is the way in which this information is visualised. As you can see, rather than listing these items out, each item is contextualised under a bigger piece of work. Besides the way the information is visualised, the key difference between a flat product backlog and a user story map, is the focus on the customer journey. Let’s unpack this by breaking down the anatomy of the user story map.
What A User Story Map Achieves that a Flat Product Backlog Can’t
- Focus on Desired Customer Outcomes: the visualisation of the customer journey allows teams to identify and implement features based on customer outcomes, and track progress at a glance against a story map
- Bring the Customer Journey to Life: the transformation of the flat product backlog to a customer centric story map means teams have a better understanding of their customer journey and what their customers want and value
- Prioritising Actions Based on Value to the Customer: visualisation of the customer journey allows teams to prioritise work based on “value to customer”, resulting in better outcomes and less waste
Are you getting lost in your flat product backlog? Are you stuck in an endless development cycle, but not really sure for who or why your building features?
Easy Agile TeamRhythm
Easy Agile TeamRhythm supports User Story Mapping, sprint or version planning, backlog refinement, and team retrospectives.