What is it and what it can help with
User Story mapping is a simple collaborative method to build a model that captures how your users would journey through the product. It can help you to do many things:
- It maps all kinds of user interaction with the product, end to end, giving the user stories chronological/sequential order.
- It helps you to designate what parts of the product has priority.
- It helps to clarify who are your users and what are their needs.
- It helps the team to understand the product, come with ideas and collect the user stories that might be relevant.
- It can help to create a backlog, giving it structure and even to create a backlog.
- It can be also used to define what is the Minimal Viable Product (MVP) or Minimal Marketable Product (MMP).
I was doing this each time when starting a new product or a new product phase. Its usable even when you are planning a new feature development. It is using a fun way to visualize a product and makes collaborate the whole team on product definition. You can then use this input to make a forecast.
It was originally developed by Jeff Patton in his book User Story Mapping. There is many more information in this book.
You need a team
Ideally the whole team is included in this activity, not just the Product Owner. The business representatives should be present to bring business context. The developers, UI/UX specialists and quality guys, they all bring their own expertise. To include them in this activity promotes the understanding of the product, its context, users and it is giving them the sense of direction in the future. As always, more brains, usually means more knowledge.
You don’t need much to start
As in many other Design Thinking methods, you need a free room with a large white board or some means to create the map that could be quite large. You need some post it notes, whiteboard or some paper to hang on the wall. In current state of pandemic or if you are a remote team this can be also done fully in digital space on a virtual collaboration tool. Actually I always used virtual boards as it can be saved right away and I don’t need to photograph the results. You don’t need any physical space. Doing it remotely, fully in virtual space has it’s shortcomings. Personal contact is always richer at gives more options of interactions.
This activity very simple and you don’t need any special training. There are no complex activities, no groups or any special coordination needed. There should be a facilitator that would guide the team and maybe a person who would act as a decider in cases there is no team consensus, but other that that there are no other roles.
Time consumption depends on what big of a problem/product you choose to map. I prefer maximal concentration, no phones, notebooks, emails or anything other. Regular breaks and doing it continually not to strech it out for few hours per day. The cost of context switching is very high. The most time consuming parts seems to me the setting of priorities and defining the MVP or MMP. The team members groups, can have conflicting ideas, you need to timebox and make final decisions.
Story mapping
So, you have a problem, feature, phase of project you need to map out. The first step you do is to bring the team together and decide on what kind of issue you want to solve (framing). If you come to an agreement what problem/feature/area you want to solve, then you can start from top to bottom.
E.g. once for me the task was to map out the full journey of a user that is testing a medical device. From the start, when he starts the application till the moment when he has the legally binding document generated. I had also mapped existing product which needed new features, but also needed structure and order to its hierarchy of work items (Epics, Features, User Stories)
With this approach you will create a map that has a structure. On the top of the structure you have users/personas/actors. You need to create a list of your potential users you want to tackle. Many times you already know who your user would be or you have done some research on in what cohorts of users you are interested in. To start the mapping you should already know this for most part. For the mapping you can create a user with a described role as: Admin, Editor, Customer,… or you can create a persona like: Kate – Woman in her 30’s with interest in education,… You place these user at the top of your map with enough space to put user stories under them and between them.
When you have decided what users you will include to the map, the next step is that you can define goals you want to achieve, activities the users will do or even map it on a feature level or epic level. The level of abstraction is really on your discretion, but it should function as an indication of narrative flow. Goals could be things like: “User is able to manage his orders”, “User knows about products he can be interested in”, “User know about his discounts”,…
The third line could be the activities, that serves as a backbone or the “walking skeleton” of the product. Start with the most critical activities, but think as wide as your product should go. Write in in simple activity statements as: “Enter order”, “Process order”, etc…
The group of items at the bottom are the user stories themselves. You add the user stories under the activities to the correct goal and user in a sequence. You have already elaborated the “width” of the product and have all the phases through which the user should go. Now invest time to go deep and do a deep drill-down of everything you can think of. You can use some gamification/design thinking methods to help the creativity as HMW, Innovation games, etc… During you create user stories put them on the map and align them vertically according to the priority. You will need to define the user story and then assess how important it is. This is doable with different methods to help designate the priority (MOSCOW, KANO model, etc…), but that’s for another article. At the first line really the absolutely essential user stories should be present, as you go lower to other layers less and less important user stories are added. Now you have a map that captures the product in its fill width and depth. With this you can start to decide what should be the MVP and MMP.
Deciding on MVP, MMP and other iterations of the product
It can be a difficult task to decide what should be the MVP/MMP. It’s not easy to agree what is really the absolute core of the product. You should not include any bells and whistles to the MVP. It is really important and you should adamant about it. The first level of the user stories in the map should be really just the MVP user stories. The MVP should be the first iteration of the product that you can already show to some users and function as basic representation of the business ideas. If you released the MVP you are really through the most difficult phase to kick off the product and now you can test the product.
The next step then could be to create a MMP. And how to define it? Basically it is the product that you would not be ashamed of :). It is a product that checks all the necessary expectations of the users from a product like yours. Now you can release it and gather data to make the decision if to preserve or pivot the product. It can lead to really hard decision to pivot, but you save a lot of efforts. About this in another article.
The baseline is that you can decide to draw horizontal lines to the map to indicate iterations of the product. You can indicate this first iteration of the product by marking the MVP with a red line above which the MVP user stories should be. Later on you can slice it further and create new iterations of the product. If you take the slices, estimate the user story in them you can create create a roadmap. Where you have the slices as milestones.
Here an example of my product that should have be trimmed down much more as most of the user stories are in the MMP:
You can see that I also indicated if the user story was already implemented or not. Above the orange row where users, under it epics, the violet part was features and under it the user stories. The red line shows the boundary of the MMP.
This is such a good tool that I consider it as an absolute must-have tool in the product owners backpack.
More to read: Simple pamphlet how to do a User story mapping by its author