User Story Mapping

Regardless of your role, if you work on a product with a disciplinary team and you must create a solution which requirements are not fully clear in the beginning, User Story Mapping could help you in multiple ways.

In this short article I will explain the method of User-Story-Mapping, learnings from one year practice and give reasons, why you should establish collaboration as soon as possible.

The Method:

The basic idea of a User-Story-Map is, that it should tell the story of the user using your solution for his problem. But the method contains more. It gives the product-team a place to discover the user and his problem in the first place. It allows to ideate and prototype solutions with people of different roles through a high-level view and additionally helps to slice the mass of ideas in deliverable outcomes.

Steps of User Story Mapping:

It doesn’t matter if you are at the beginning of your project or in the middle of it. Just starting with this method can help to get a better shared understanding of the big picture the team is trying to achieve.

1. Start with framing the problem. Who are your users and what are their problems? Why should they use your solution? You might speak directly to users or start with assumptions. The important thing is that you collect and speak about your assumptions in your team.

2. Then try to map the big picture. Get a post-it, write what you think the user is doing or should do as an activity and place it on a whiteboard while explaining it to the other participants. Continue with the complete flow till the story is fully spoken. Mostly it is needed to create further post-it’s as steps, which the user must take to fulfil the activity. Of course, you can go into discussion when placing the activities and steps, but in this stage try to go into the breadth, not into detail. If you have clearly no idea what the users should do in a perfect solution, start with the current state of how the user handling the problem.

3. After getting a first overview of what the other participants think the user needs and how we could achieve that, go deep into different activities and steps. Try to prototype some, ask users if your map displays their problem well and with the feedback iteratively refine the map. While doing that you can enrich the steps with details, information, or alternative solutions by placing them below.

4. If you have finished your map, it might be a really big collection of different ideas and way to big to be created. Then you should go and slice out releases that includes the most important. Just put a line horizontal in the map and move the details down, that should be included in the release.

5. Sometimes you don’t find a release small enough or your discussions don’t find an end, just tag the activities, steps, or details with different indicators. For example, you could come up with a tag that represents all post-its which stand the solution apart from other competitors or tag risky post-its. That often helps to find things you should or shouldn’t do in the first place.

6. As a last step you should slice the releases further, that they fit in a sprint for implementation.

Benefits:

Now after reading the six steps of using User-Story-Maps you might ask yourself, why you need to participate if this is obviously a product-design thing. Me as a former developer and now product-manager can say that the expertise of every role in the team is a crucial part of this method to work. It isn’t about the map that coming out from the workshops, it is the shared understanding of the user, the problem, and the solution in the team.

It isn’t necessary that everyone in the team takes place in every workshop. But I think it helps to have one person from the major roles in the team, in our case the product owner, a user experience designer and a senior engineer. Despite the shared understanding, this group of different roles help to find the sweet spot between value, feasibility, and usability.

Especially for developers it can be helpful to understand the bigger picture before working on a task, to be able to zoom out and know what the activity in front is or after from the user-perspective is. In addition it is a great opportunity to contribute with risk-, complexity- and feasibility-expertise.

What worked and what doesn’t:

• Establish product-workshops in every sprint, in which the story map was the starting point for the upcoming discussions. Worked well.

• Ask the simple questions “In which scenario the user needs this?” or “How that helps that the user reaches his goal?”, when the outcome of a post-it is not clear. Worked well.

• The product owner creates the story map in private. Didn’t work.

• Try to build the one User-Story-Map, that contains all details. Didn’t work. Better try to hold it simple. The details can be better written down as acceptance criteria later. Otherwise, it will take you a mass of time and in the end, no one wants to use it anymore, because it is too big.

Find your own method:

In the end every team must find its own way of getting the big picture. If you think you don’t know what the big picture or even the bigger epic of what you are working on is, User-Story-Mapping might be a good fit for your team. If you want to read further, I can suggest “User Story Mapping” by Jeff Patton, which is the bible of the method and “Lean UX” by Jeff Gothelf and Josh Seiden, which focuses more on general user experience in product teams but engages well with the method.