Leveraging User Story mapping to anchor your MVP

Photo by rawpixel on Unsplash

In this post we will touch on the value of User Story mapping and how it relates to anchoring your product to commercial value. (This may turn into a multi-part series but lets just start here for now…)

Story mapping is an important part of software development, it plays a major role in the initial phases of a project. I rely on its ability to provide structure in this chaotic agile world. Story-mapping is an activity used to provide a graphical representation of a users journey through a product. It initiates conversations and ensures the user is the primary focus of our products.

A Developer, Tester, Product Owner and Business Analyst (me) (maybe some SMEs) sit down together and discuss the product we are about to work on. As a group, we start by identifying and recording our users journey through sticky notes or another visual format. Then we display these notes sequentially for all members to see. We look for similar groupings of journey notes in order to start building out the journey map. Here is an example of how we would map out a user journey for a new customer making a purchase from an online store.

Group similar user journey cards together such as; Searching items and browsing items.

Now that we have mapped out and grouped the user journey, we have our product’s features. A feature is a part of the functionality of the software, it is generally too big to be one user story. Each feature is broken down into small bite size pieces of work, these are called stories.

The key to this story writing task is keeping each story as small as possible, without making each one dependent on the other (I believe the text book term is acronymed as ‘I.N.V.E.S.T.’). This means, stories can be done in any order without relying on any other story to be complete. These story cards can be stuck below their respective feature card, going vertically down the board, repeat this task until you have gone through each feature. Once this task is complete, your board will start looking a lot more fleshed out.

As you can see above, we now have stories for each feature. These stories can and probably will be split and broken down further as they get elaborated. How we go about splitting stories in Elaboration is a topic for perhaps another blog.

Story priority should be based on what provides the most value in the least amount of time, referred to as your minimal viable product or MVP. There are many methods of doing this but I like to keep it simple and categorise stories with the group as ‘must have’ & ‘nice to have’. ‘Must have’ stories remain higher on the list and ‘nice to have’ stories are moved towards the bottom. Once again we repeat this for each feature and story. It should look something like the diagram below.

The story hierarchy makes more sense now

Now it’s time for the Developer and Tester to size each story. As we are still working at a high level, I like to use t-shirt sizing estimations. How much work is involved in accomplishing each story; S, M, L, XL. I know some prefer to size before prioritising but I don’t. I always put the customer first, customer satisfaction is my primary indicator for project success. I favour business value over fast delivery. Once we have estimated, we can determine two more pieces of information:

1. Our Epics — Epics are large chunks of work comprising of one or more features. They are the backbone of a project and help provide a high level structure of what is ‘done’ and what is ‘in progress’. However, determining what an epic is, is quite subjective. There are no set rules of what a large chunk of work is. We group features into epics based on the size and the effort required. It can look something like this:

This is grouped based on sizing and related features.

2. Our sprint runway — This is a rough timeline of how long it will take to complete our MVP and our additional ‘nice to have’ stories. If you release after every sprint, this runway also shows how many releases you will need to accomplish the MVP. To determine how many of your stories go into a sprint we rely on the sizing and priority exercises completed earlier, along with the estimated capacity the team can achieve in a sprint.

This will conclude the final step in your user story mapping session and you will most likely have a board similar to this:

Red sprint lines can resemble the products MVP and the black sprint lines are the nice to have stories

Summary

In my experience, user story-mapping can take anywhere from 2–8 hours to complete. In this time, a timeline is created to provide a structured view of the project.

You know you have done a successful Story Map when your outputs are:

1. Customer centric conversations
2. Team collaboration
3. Initial identification of your MVP
4. Finger in the air indicative time-frames
5. Providing a structured approach to identifying Epics, Features and User Stories
6. Transparent stakeholder high-level view of the product or project

Thanks for reading — my name is David Rizkilla.