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;

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.

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.

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.

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.

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.

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.

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?

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;

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.

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.

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;

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.

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.

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.

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.

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.

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.

Related posts:

Flask is one of the most popular, lightweight Python web frameworks around. A self-proclaimed “micro” framework, one of Flask’s best features is its batteries-not-included ideology. While it’s small…

Have you ever found yourself wishing you knew how to take better travel photos? Do you enjoy travel photography but you want to “up your game” a bit? Well, then…we have the advice you need! This post…

Less than a year of time had passed and I was almost sixteen years old. I had spent hours and hours practicing the basic riffs of classic rock, preparing to become a rock star. My cousin and brother…