When does story mapping help?

Recently, I attended a workshop by David Hussman, and story mapping was one of the topics. Since I had rarely used story mapping, while didn't realize its Indispensability, it made me think of why.

• Why story mapping?

The introduction of story mapping technique is a response to lack of context for user stories. When you have many small stories, you lose the context and don't see the big picture. Those stories have to be combined to create complete user experience. The complete user experience is also called scenario or customer journey.

• Use case

However, in my experience of developing telecom systems, i have never encountered this problem. To be honest, we seldom used user story, because telecom systems are not really user oriented and user intensive. We used to think in use case. When I compare story map with use case, the customer journeys in story map are similar to main success scenario and extensions in use case. Then, we simply take those customer journeys as PBIs (Problem Backlog Items) without splitting them into steps-based user stories.

• The process of writing user stories

When we work on user stories, it's common to brainstorm around user roles. Typically, we derive user stories from user tasks. Then, we find that some user tasks have to be combined in order to complete a journey. Therefore, story mapping becomes very useful, even necessary in order to understand the context and see the big picture.

• The process of writing use cases

However, if you write use cases, it starts with actors. More precisely, you start with primary actors and its goals. There is use case for each goal, and each variation for achieving the goal becomes main success scenario and extensions. You don't start with supporting actors, while the tasks done by supporting actors are necessary to achieve the goal, thus, they are pulled into the diagram.

• Change the process of writing user stories

If we apply use case thinking, we can modify the process of writing user stories a bit.

Think about primary users/personas, not every user who is interacting with the system.

Think about goals from primary users/personas, not tasks from them.

By doing this, you get stories to achieve goals, rather than stories to do tasks. In this case, those stories are scenarios and customer journeys.

• Examples for clarification

For scenarios and customer journeys in products and systems with rich user interaction, it is still beneficial to clarify by examples, where the scenario is clarified by listing all the tasks/steps it goes through. Those tasks could be initiated by primary user, but also from supporting users and systems. However, those tasks may not be, or preferred not, regarded as stories.

• Story splitting

The other way to look at this is from story splitting. Take scenario based stories, if they are too big for delivery, we figure out how to split them. There are many splitting ways, with splitting from steps as one way, even not the recommended way, since those steps alone don't achieve user goal, thus, not really valuable.

• Collaboration

So far, we compared story map with use case from its thinking process. Traditionally, use case mainly acts as a way to document the system, while user story and story map are mainly to support the communication. Story map is more visual and often exists in physical space, while use case is often written in document with UML notation. With Agile modeling, it doesn't have to be so, though.

It helped me understand story mapping and its implication by thinking this through, does it help you?