User Story Mapping For Startups

In 2005 Jeff Patton introduced the concept of ‘Story Maps’, the premise is that an itemized list view isn’t the most efficient way to visualize or prioritize a product backlog. A user story map is a way for teams to understand the impact of individual user stories and how they relate to the larger initiative, thus making them a more efficient way to plan product releases.

The main output from the exercise is a complete customer journey within the product or feature, including the key activities and individual tasks they perform. Since a user story map is a collaborative effort between all members of the wider-team, it also ensures that each contributor feels a sense of ownership and direction.

This exercise is a collaborative effort between all levels of an organization, and as such, it’s vital that you have as many departments represented as possible. This is primarily because a user story map is intended to be a holistic view of the product end-to-end.

Typically, the teams below are represented; however, this is usually specific to the organization and the configuration of your teams;

• Product

• Design

• Engineering

• Customer Success

• Marketing

• Sales

• Ops

Some benefits of user story mapping

Delivering value early and often

User story mapping is an efficient way of defining an MVP and planning future iterations that will bring the most value to users. This process forces teams to trim the fat and only focus on impactful work that will lead the most significant user learning, which will, in turn, inform future iterations. It helps shorten the learn, build, learn loop.

Surfacing dependencies

An additional benefit of user story mapping is that it helps teams visualize potential blockers, risks, and dependencies by giving them a 10,000ft view of the entire product.

Prioritizing the right work

Since a user story map is a holistic visualization of all the work necessary to deliver a complete product experience, it can help product teams decide what features will have the highest user impact, what work needs to be deprioritized, and finally, in which order should each feature be released.

Clear and well-sized requirements

User story mapping helps teams understand how each task is related to one another and how they fit into the large piece of work. One benefit of this visual approach is that it surfaces linkages between different tasks and illustrates how more extensive work is broken down into smaller deliverables.

A consensus-driven approach

The process of building a user story map gives teams a shared view of the user experience and the intended journey within the product. The entire exercise is consensus-driven with representatives from each department, sharing in the creation and scoping of work.

User Story Mapping In 7 Easy Steps

I’m going to breakdown the specific output from each step in the user story mapping exercise by looking at my morning routine as a product.

Step 1: Frame the journey

At the start of the exercise, it’s crucial that you identify a specific persona impacted by this new product or feature and then rally the members of the team around a defined user problem.

One of the easiest ways is by starting the session with a single question; what is the problem we are trying to solve? This is typically followed up by how does this fit into our product vision, and what is the potential revenue uplift we expect to see as a result of rolling out this product or feature?

Step 2: Build the backbone

Now that we have defined the problem statement and reviewed how it fits into our vision, it’s time that we build the backbone that will carry our activities and tasks. The backbone is the user journey set out in sequential order at the highest level; the aim of this part of the exercise is to go wide instead of deep on details.

Using the example of my morning routine, at the highest level, the steps I would take are;

1. Wake up

2. Get ready to leave the house

3. Have my morning coffee

4. Commute to the office

5. Get settled in to start work

Once this is complete, and you have rearranged these steps into a sequential order, they should now fit into a narrative flow. The user map is quite literally a story that has a beginning, a middle, and an end. I suggest that you review the backbone multiple times to ensure that you have identified and created the most optimized user flow.

Step 3: Identify & group activities

Now that you have the fundamental story defined and outlined, you might start to notice themes emerge. These themes that work towards a common goal are called ‘activities’ within the user story mapping exercise.

A user story map should be thought of as having two axes; the first is horizontal which contains both the activities and the backbone, while the other runs vertically and cascades from each activity as individual tasks broken down into deliverables.

Step 4: Break large tasks into subtasks

It is at this stage that we should start to review our defined backbone steps and begin to break them down into smaller tasks and user stories vertically.

It should be expected that you will probably end up rewriting tasks and activities multiple times before you have a set backbone and agreed-upon tasks, don’t be afraid to start fresh.

If your team starts to hit creative turbulence, Jeff Patton provides some suggestions to keep the creativity flow;

1. Play ‘wouldn’t it be cool if…’: It shouldn’t matter what your title is; no one should have a clear ‘No’ to any suggestion, use ‘blue-sky thinking’ and make it a fun activity.

2. Look for variations: every task, regardless of the output, should have multiple paths to success, and each path has tons of opportunity in the peripheral.

3. Look for exceptions: Review indirect paths to success and unique journies that a user might take, look for potential issues and how they affect your user story map.

4. Consider other personas: Other than your primary user persona, how would different personas act at each step in the user journey? Consider as many relevant personas as possible.

5. Add in other product details: Consider the usability of the product/feature, the business cases involved, the use-cases, and other indirect inputs.

There shouldn’t be any concern about scope or feasibility at this point, focus on idea generation. In later stages, we will scope and validate ideas.

Step 5: Fill in the blanks

The user advocate should at this point be reviewing the journey with the team; the most important thing is to ensure that all relevant personas are accounted for and that there are no gaps in the user journey. The user advocate should go through the hypothetical flow while the team starts to note missing steps or unaccounted for flows.

The benefit of having a representative from as many departments as possible is that it allows everyone to contribute from a unique vantage point, a developer will tell you with a task is too big, while a designer will tell you where there might be a missed step.

Step 6: Prioritization

The backbone items are critical components of the overall user journey, and each step contained in the backbone is necessary to move to the next one. The flexibility that lays in the individual tasks that pertain to the activities in the backbone

Prioritization is critical to ensure that the right items are worked on in the proper order, the team should, therefore, move items either up or down vertically for each activity to sure that the highest impact item is set first while the least essential item in each stack is placed last.

Step 7: Planning each release

At this point, you should be able to clearly articulate the user journey in your product/feature given that the user story map is complete. Your activities should contain your user steps with a list of tasks cascading from each step.

As previously mentioned, the user story map houses tasks vertically, while horizontally; it contains the user steps. It’s in the horizontal view that you can cut left-to-right and define a subset of work, or in other words, an iteration.

Each iteration should have an expected outcome and success metrics clearly labelled alongside the slice of work, in fact, creating success metrics should be easier given that you can look at the product/feature holistically as well as individuals using the user story map.

The user story map is done, what now?

With the user story map complete, you should have your iterations and success metrics identified.

The transition from user story mapping to sprint planning should be fluid given that the team should have identified each release and block of work, it should be relatively easy for your team to scope work and surface dependencies.

The main output from the user story map

1. An easily understandable development plan that can be used for sprint planning

2. Iterations clearly scoped with prioritized activities and tasks

3. A single team definition for the product/feature

4. A visual representation of the entire product/feature and the potential value for the users

As with all planning tools, the information contained in the user story map becomes outdated the moment it’s completed, so it’s crucial that an owner is elected to maintain the user story map.

A user story map is a powerful communication tool that can be used in planning session as well as stakeholder discussions, keep it updated and keep it relevant.

Nabi Awada is a product manager, strategist and entrepreneur with over 15 years experience in the development and management of consumer and enterprise web & mobile software. He can be reached via Twitter, Linkedin or his website.