Ultimate guide how to conduct User Story Mapping sessions effectively

The deciding factor of a product’s success is the value it adds to users. When involved in an exhaustive development process muddled with dozens of tasks sitting in the backlog, though, people often make the mistake of losing perspective of the users and what matters to them.

It’s one of the reasons why we see the practice of user story mapping and Agile go hand in hand during product development processes today. When you’re buried in a project backlog full of user requirements, proposed features, enhancements, and fixes, user story mapping helps you build a structure to recognize which tasks actually add value to the users at a given moment.

Even as user story mapping becomes increasingly popular among Agile teams today, many still struggle to run these sessions as a method of building a shared understanding of the product and its purpose.

What steps should you follow to conduct an effective user story mapping session that yields the best outcome to both product developers and users? What other tips should you consider when organizing such a session for your product? These are the questions we will answer in this post today to help you maximize the efficiency of an Agile development process.

What is user story mapping?

The concept of user story mapping was first introduced by Jeff Patton to answer the shortcomings of the flat backlog used with Agile in the earlier days. It converts the confusing and overwhelming one-dimensional flat backlog into two-dimensional

visualization of a user’s journey with a product: the horizontal axis records the steps a user may follow when interacting with a product, while the vertical axis records the priorities of the tasks listed under each step.

Organizing the tasks in your backlog in this structure simplifies the process of understanding what adds value to users by continually forcing you to put yourself in their shoes. At the same time, it helps your team build a clearer shared vision about the product and its purpose.

How to conduct a user story mapping session

In an Agile process, the user story mapping should happen before the actual designing and development phases. In fact, you can jump straight into creating the map once you have collected the project requirements.

We can divide the execution of a user story mapping session into seven key phases. It starts with understanding the purpose of the product and ends with testing the developed map for any inconsistencies.

Understand the purpose of your product

The success of the user story mapping process, and in extension, the development process, relies heavily on the team’s understanding of the purpose behind building the product. The first phase of a user story mapping session, therefore, is reserved for establishing a shared understanding of the product and expected outcomes of the development process among team members.

Discover User Persona

Though there isn’t a fixed criterion for leading this discussion, it should at least clarify the answers to the What, Who, and Why questions about the product.

  • What?
    • What product are you going to build?
    • What features should/could it include?
  • Who?
    • Who are the target users of this product? How does the product benefit these users?
  • Why?
    • Why are we building this product? What value does it add to your company/team and customers?

Understanding these crucial details about the product early on allows the team to act decisively and cohesively when prioritizing the user stories in later steps.

Build the backbone and skeleton of the user story map

Backbone and skeleton are the two essential components of the user story map. In the simplest terms, these are the activities that form the high-level abstractions of the user’s journey. From the two, backbone, as the name suggests, provides the highest level of abstraction. It contains the essential activities the user has to carry out when interacting with the product. If we take the previous online store example, its backbone should include at least the following three activities.

  • Select product
  • Register
  • Buy product

The skeleton, on the other hand, goes a little deeper to list the key steps a user follows under each backbone activity. However, as the skeleton is another abstraction of the user’s journey, it also doesn’t focus on the specific actions a user might take based on

their preferences. If we define the skeleton of the online store under the backbone we already have in place, it might appear like this:

  • Select product: Search product, View product listing, Add product to the cart.
  • Register: Sign up, Sign in
  • Buy product: Enter delivery location, Enter payment details, Confirm order.

The activities in the backbone and skeleton are placed along the horizontal axis of the user story map according to the order they are executed. The backbone should sit above the skeleton in a way that makes their grouping apparent. Forming a good backbone and a skeleton of the user’s journey is crucial to understanding what the user expects from your product and what truly benefits them when making decisions.

Add user stories relevant to each step

Screenshot of Agile User Story Map and Roadmap for Jira

With the backbone and skeleton of the map already in place, now it’s time to list all relevant user stories in your backlog under each step in the skeleton. At this stage, there’s no need to focus on ranking stories according to their priority. With the stories in your backlog spread across the two dimensions of the user story map, you’d be able to quickly realize which steps of the user journey take extra effort to roll out and not. Having a complete and diverse backlog of user stories plays a significant role when deciding the success of this step and the overall process. Therefore, developing a good set of user stories is something you’d have to execute carefully before entering a user story mapping session.

Create new tasks for relatively large stories

Some user stories you add to the map in the previous phase could contain more than one actionable task associated with them. Breaking down such stories into separated tasks under the same activity allows you to identify and prioritize them according to their true significance to the user.

Rank the stories based on their priority

With tasks necessary to implement each step in the skeleton finalized, now you should position them along the vertical axis according to their priority. Give the highest priority to the tasks necessary for developing a Minimum Viable Product (MVP). Position the tasks that have lesser priority as you move down the vertical axis.

When assigning a priority to a task, it’s vital that your thought process reflects the user’s needs and wants rather than a technical perspective. The “why” reasonings in user stories are an excellent place to understand how a particular task benefits the user and provides them a better experience.

Divide tasks into sprints

Staying true to the iterative Agile development process, you can use a story map to separate your workload into sprints. Each sprint moves along the user’s journey recorded on the horizontal axis, with tasks categorized under different steps. While every sprint should contain tasks representing all backbone activities in your map, it’s not necessary to add tasks belonging to every step in the skeleton for every sprint. The only requirement is that each sprint contains a set of tasks that justifies its timespan and adds value to the users.

Naturally, the first development sprint should contain the tasks for building an MVP for the users. You can draw horizontal lines across the user story map to separate tasks belonging to each incremental sprint.

At this point, the user story map gives a clear view of the development plan you intend to follow, along with the logic and context attached to your decisions. Throughout the development process, you can go back to this user story map to remind yourself how the functions and features you’re building impact the user’s experience.

Test the story map for inconsistencies

One important action you should complete before wrapping up the mapping session is testing your user story map for any gaps and inconsistencies.

Walk the tasks and stories in each sprint with users, developers, or other stakeholders and explain how the user’s journey progresses as you go along. Present it as a story with a continuous flow so that you or the one you’re accompanying can spot any inconsistencies when they show up. Add additional tasks as necessary for any missing details you discover during this process.

Involving stakeholders who weren’t initially a part of the mapping session will increase the effectiveness of the testing process as they can analyze the story with an untainted perspective.

Once the testing completes, your user story mapping session concludes with a map that helps you understand and structure the development process better.

Additional tips on creating user story maps Who should participate in a user story mapping session?

It’s a best practice to finalize all the attendees of the mapping session beforehand with the roles they are expected to play defined. While the exact personnel involved in the process may vary depending on your unique requirements, you can consider inviting the following people.

  • Product owner
  • Project sponsor
  • Development team
  • UX designer
  • Marketing lead
  • Data analyst
  • Customer support person

As the number of people involved in the development process increases, you might unknowingly find yourself with over 20 invitees. However, to work at high productivity, keep the attendees count around 10-12 by eliminating those who cannot make a considerable contribution to the process. In addition to these participants, you also need one facilitator to manage the flow of the session. In a scrum team, the facilitator could be the scrum master. Otherwise, you can invite a product manager from another team to ensure the process remains unbiased.

Focus on one user persona type at a time

Conducting a user story mapping session with several user personas with different requirements can easily become confusing and overwhelming. A better execution plan is starting with a user persona that represents the majority of your user base. It gives you the chance to capture the tasks that have the most impact and incorporate them into the user story map.

Once you’ve completed prioritizing the tasks related to the first persona, you can focus on others that represent unique sets of users of your product.

Good user stories are essential to the success of user story mapping

Good user stories are the deciding factor of how well your user story map captures user experience. Therefore, before the beginning of a mapping session, you should pay extra attention to developing good stories and acceptance criteria for representative user personas.

You may need a new backbone when adding features to an existing product

When adding several new features to a large existing product, it may already have a user story map with a defined backbone. In that case, updating the map to integrate the new features can become a cumbersome task.

As a solution to this problem, you can choose to develop a new story map, just for those features, with a new backbone. It will be considerably smaller than your original map and won’t take as many hours to develop, but it will help you understand and prioritize what needs to be done in a short time.

However, this is not a suitable course of action when you want to make significant changes to an existing product.

Where should you create your user story map?

If you can physically meet your team to conduct the mapping session, using a whiteboard or similar spacious area is the best way to build the story map. It gives you the freedom to write down the activities and tasks on sticky notes and move them as you

need when structuring the map. You can also color-code different tasks based on categories or sprints to highlight the details.

Once you’ve created the user story map, you can move it to a virtual space to ensure ease of sharing and tracking as development continues. If you’re using Jira to manage your Agile workflows, you can easily integrate the agreed-upon map with your Agile board and project using our Agile User Story Map & Product Roadmap for Jira application. It provides you tools to map user stories in your backlog and plan your sprints and releases around them without a hassle.

Conversely, if you’re a virtual team relying on technology to complete your mapping session, you can again use our Jira app to create your user story map collaboratively.

Wrapping up

User story mapping is a backlog structuring method that goes hand in hand with Agile development today. It provides you a basis to focus on the user and their needs throughout the development process and beyond. If your team follows what we discussed in this post on conducting effective mapping sessions, you’ll be able to make your sprint/release planning processes less stressful and more rewarding to you, as well as the users, especially with the support of our Agile User Story Map application.

 

 

Culture that Fosters Scaled Agile Adoption

Launch of Your First Agile Release Train?

User Journey vs Journey Map

Try Agile User Story Map and Roadmap for Jira NOW!

Jira Cloud Jira Server Jira Data Center
User Story Map for Jira

About Us

Devsamurai is Atlassian solution partner in Japan. We extend Atlassian products and implement applications to empower all teams worldwide. All our products are built and supported in our office in Japan.

Office Location

DevSamurai, Inc.
4F Shiroyama Trust Tower
Toranomon 4-3-1, Minato City
Tokyo, 105-6004 Japan

atlassian@devsamurai.com      
+81 50 362 78910      
Go to top