User Story Mapping – Steps to Success

User Story Mapping has been described as a niche tool to achieve much. Tools for product development, feature definition, version improvement and project management just to name a few.

In this case we are looking at the steps to success, utilising User Story Mapping methodology to help define your path. The first two steps instantly reward.

Firstly, planning the map rewards you a pathway to the point so that you can start writing user stories (a user story is a short description of something your customer will do when using your product).

Secondly, the end result is a visual chart showing the structure of your stories which gives you the steps to development.

Here is another way to approach User Story Mapping in three steps and this is a relatively quick way of getting to a point to start development work.

A finished User Story Map example.

Hosting your Story Mapping Session

Because User Story Mapping can come across as complex it is important that management of the session is approached with a framework. Needless to say that User Story Mapping can be a new tool for most people so outlining what it is all about and describing the process is important.

Start with tasks where the team thinks about the product, users, development and personas.

Step One

We start by brainstorming every task that users will want to address when using the product.

Silent Brainstorming. Task each participant to write down steps in your cards, every step will need to cover from the users first engagement to the conclusion of the users interaction.  Encourage the team to think of these as actions not features.

Top Tip: Writing them so they start with a verb is a good technique.

Encourage people to be creative and try to cover tasks and steps wide, but not deep. This part of User Story Mapping is about breadth not depth.

Start posting all cards and tasks in one large map. Thats fine, you’ll have duplicates, and these should sit beside each other on the line (not above or below). As you expand and learn you can easily drag and drop and delete if needed. The beauty of using digital software for large collaberation tasks such as this allows you and you and your team to easily edit, expand and develop your map.

This first line is the user tasks and they form the backbone of your story map.

Step Two

Then we organise these tasks into wider goals, and arrange them in order of completion.

These groups are known as “epics” or “activities”.

As facilitator you can walk along the line of tasks and ask where the team think the splits are between each group of tasks, and what each group should be called.

For example, if you were building an app for an app to arrange your movies you might group user tasks into epics like this:

Browse DVDs in collection – epic
View flat list of all DVDs – user task
View DVD cover thumbnails in results – user task
DVD Spec Call – user task

Step Three

We can then move into the Prioritisation exercise, further developing the user story map.

This is the stage where you start writing in the details, building up the tasks and redifining tasks. This may include adding tasks, merging tasks or seperating tasks.

It is important to detail the tasks enough to remember in the future.

After writing all the tasks, you should have a comprehensive map by this stage.

Task your team to go over each line (now defined as Epics/actitives) and ensure you have everything charted. This is where the User Story Map will become easier as you will now have a visual chart of a defined product. Here you can move to the next steps.

The Moviebuddy Current Version

Next Steps

Now you are ready to start prioritising the user stories on your map. You can start adapting and moving your tasks to sprints, also known as versions for your product.

You can check out the Movie Buddy Public Board here at FeatureMap.

You can do this all with Post-It notes with your in house team, or digitally using FeatureMap.co with your teams remotely and digitially.

Check out FeatureMap.co and sign up to try for free.

How to re-write your Legacy Application using Story Mapping

People often mistake User Story Mapping as a tool to start projects, but it is entirely suitable for building up an old project or design.

When looking at your application it is easy to first create  User Story Map based on the products functions.

Establish the tasks, the goals and flesh out the map. Sometimes you may taken things for granted and forget certain tools of the application are actually tasks so it’s a good idea to bring in people from other teams to help identify all the functions of your project.

Build the map, identifiying all the functions.

We once took an old tool and needed to update the codebase, as well as introduce new features and improvements.

A few options may be available to you, depending on the code. Are you able to update the tool in sections? Are you able to approach the update in sprints/versions? Do you need to rebuild the entire program from scratch?

We first built the map of our tool, you can see below our “Moviebuddy” example.

The Moviebuddy Current Version

We then worked through identifying which sections were redundant. We identified these and added them to a new column to the side. Essentially removing them from view.

We then talked out and identified which parts of the code would be updated and what we could do first. We labelled this as version 1 and aimed to get the core functions updated.

Identifying what we should upgrade first in Version 1

We were able to identify one function which we were able to upgrade. We also added new cards which reminded us to update our code standards and highlighted them green to ensure they were completed.

We then moved along to the next version which allowed us to introduce our new payment gateway to the application. A function that had alluded us due to the old codebase.

Adding a new Codebase column and moving to version 1.5

This allowed us to deploy more frequently and provide value sooner as we updated sections of the site. We still had a lot of ‘old legacy code’ but as we added new features we moved the legacy code functions inline with our updates.

As you can see using User Story Mapping can be brand new projects, or old existing projects.

Moviebuddy is all fictional for the purpose of training.

 

User Story Mapping : From Idea to MVP

When we look at User Story Mapping, you may think of the backlog of user stories, or how it can be a great methodolgy to reduce and refine your current project or product flow. But User Story Mapping doesn’t just need to be a tool applied to a backlog heavy project. It can be used to refine an idea to a product.

Refine the Idea

Take the product and ask yourself and your team these questions:

  1. What is the overall idea?
  2. Who are the customers?
  3. Who are the end users?
  4. Why would they want it?
  5. Why are we building it?

Find out what the project and product is for, validate your reasoning, search for problems, take the steps now to refine your idea.

Build to Learn

With the initial idea fleshed out, first build your product with the aim to learn. A less than MVP (Minimum Viable Product), a product that covers the simple basis for your users.

With this stage you do not want to market, push or give out the product as “The product” but to a small group of users. Ideally users you spoke to initally that may have sparked the idea of the product.

As part of this step you need to harvest the feedback, and constantly refine your idea. Build wants but be care ful to actually listen to what the user wants.

At this stage metrics will help as it is common people will fall into a loose three categories:

  1. The Polite Enabler. — The user who says everything is great, but doesnt use the product.
  2. The Complainer. — The user who sends in lists of feedback and demands, but actually uses the product.
  3. The Mute. — The user who uses the product and says nothing.

The polite user is probably the worst for building to learn, with the complainer being your favourite user. However be careful the complainer is not just demanding features that detract or do nothing.

The Mute you’ll need to reach out, engage and ask for feedback with offered incentives. The mute can be valuable.

Applying to Story Mapped Backlog

You now have your project released, some feedback and ideas of how to take it from big idea to big success.

We recommend organising a horizontal strip of User Actitives. You will have this from the first step, and the questions. This will form the backbone and be the foundation of your map.

Below in vertical strips arrange into three tiers:

  • Current Relase
  • Next Release(s)
  • Future Ideas

Each card will have indepth details about the feature.

Example Layout in FeatureMap.co

Then when organised, take the highest priority stories or layers and move into the current sprint.

This is one great way to take Idea to MVP.

Common Pitfalls

I might write a piece entirely about the pitfalls I see new projects and products fall to when designing their story map and MVP.

  1. Perfection — When designing a product do not focus and lose yourself to the “Just one more feature” which adds time and bloat to inital ideas.
  2. Make a skateboard first — When making a car, first design a skateboard that allows the user to at least get somewhere. Do not fall into the trap of building car parts with no method to go.

To illustrate this Henrik Kniberg wrote an article talking about how he prefers “Earliest Testable/Usable/Lovable” over MVP.

Validate your MVP

When designing your product, each sprint sent to product should be reviewed, measured and with feedback and data — learn.

With that learn knowledge refine your idea.

With that refined idea, revamp your MVP and build.

  • Build — MVP
  • Measure — Get feedback and data
  • Refine — Improve with better ideas
  • Repeat — Back to Build.

With User Story Mapping this is easy, especially when using a tool like FeatureMap.co as the ease and flow of a team all working, moving and adjusting cards on the fly makes it invaluable.