8 Steps To Developing A User Story Map

User story maps are an interesting and collaborative way of eliciting user requirements. One of the reasons why I find it so powerful is because it provides a unique approach for aligning discussions relating to the user, their goals, the process that supports the accomplishment of their predefined goals; and the requirements that need to be addressed to solve business problems. 

If you haven’t worked with a user story map before, this article highlights 8 straightforward steps you can follow to get started with your team or participants.

Materials You Need

To get started, you’ll need the following materials:

-       Self-Adhesive A3 paper or a whiteboard

-       3 different colours of post-it notes

-       Markers/pens

Each colour of post-it notes would be used to indicate:

-       Activities

-       Tasks

-       Requirements/User Stories

If you are using a digital whiteboard such as Miro, you could make use of different “boxes” to indicate the category of information you are trying to capture.

Step 1: Determine the process name

Define or identify what process is to be assessed. This step is particularly useful for determining the scope of the improvement effort. The last thing you want is users brainstorming without clear boundaries defined upfront. Once you’ve determined what the process name is, you would want to capture this on the whiteboard or Adhesive A3 paper.

Step 2: Define the objective

The next step involves identifying the objective that needs to be met. This will help to define what the product needs to do to solve the identified business problem. You may have one or more objectives.

Once you’ve defined this, you may then take note of it using the whiteboard or Adhesive A3 paper.

Step 3: Define the user

At this point, it’s important to clarify the role or user that stands to benefit from the change that is being sought. This is an attempt at answering, “Who is this system being built for? Once you’ve written this down on the whiteboard/paper, you may want to review the objective(s) noted to confirm that there aren’t any additional objectives or user roles to be documented.

Step 4: Build your process backbone (use post-it notes)

This step involves describing the high-level steps or tasks involved in accomplishing the predefined goal(s). Each step should be written on a post-it note, with the notes organized in sequence. Participants may jot down the steps while the facilitator can help organize the steps in sequence. Don’t get too detailed at this point and try to keep participants focused on a specific version of the process. For example, you may want to focus on the “as-is” and not the “to-be” version of the process.

As you identify the tasks that form the process backbone, you may then choose to break down high-level tasks into subtasks as you go. Don’t focus on scope at this stage. 

Step 5: Identify and group activities (use post-it notes)

Activities in this sense, are high-level groupings of tasks and can be used to group tasks that are performed within a single functional area, for example. This step is all about identifying common themes.

Step 6: Identify High-Value Areas & Pain Points

Once you have the entire mapping done, it’s time to step back and evaluate what is missing or identify pain points/challenging tasks. 

Step 7: Identify Requirements (use post-it notes)

The next step involves identifying the technical requirements that need to be met to aid the fulfilment of tasks. Each requirement should ideally be lined up with its overarching task. 

Step 8: Prioritize tasks

This step involves prioritising tasks and arranging the high-value items based on techniques such as MoSCoW or using different markers to indicate the level of priority of each task.

In addition to identifying technical requirements, an end result of this exercise is a list of tasks (which translate to supporting system features) that need to be planned for system release, also known as an “iteration”.