Story Mapping versus Business Process Modeling

User Story Mapping

Story maps are great. Together with a small team of stakeholders you can analyze a business process in 45 minutes. Use these steps:

1. First, gather the user stories that are to be executed during the business process and record them on slips of paper. (Often people refer to tasks, but this is misleading, as tasks refer to what programmers do to implement user stories). It makes sense to use the items that already exist in the product backlog.
2. On a blackboard or table, arrange the user stories from left to right in chronological order. This will give you the “narrative flow” of the business process. Some people call this a “customer journey.”
3. Now consider alternative sequences. Are there exceptions? Problems or special cases? A passing lane? The normal sequence is placed on top, and the variations are placed under it. The higher up a user story is placed, the more important it is.
4. Now gather user stories that are executed together into activities (epics or features). These activities are written slips of a different color. They give the story map structure or backbone. It’s also possible to assign these activities to user groups.
5. Finally, group the users stories according to goals (outcomes) in horizontal rows. These outcomes can also be used as the basis for release slices or sprint backlogs. In other words, you’re grouping user stories that are to be implemented together.

The procedure described here is bottom-up. As in business process analysis, the user story map can also be built up from the other direction, that is, from less to more detail. Concretely, that means you would start with the activities.

Business Process Modeling

The procedure above looks a lot like business process analysis, where functions are also ordered from left to right, supplemented with special cases, and assigned to users. Is the agile community being given old wine in new skins?

Yes and no. Despite the similarities, there are also important differences.

• Interactivity: In classical business process analysis, a consultant is responsible for creating the digital model on her laptop and acts as a gatekeeper, accepting or rejecting suggestions and changes with her keyboard. Story mapping is hands on. Anyone can take a slip of paper and a pen and get involved. This means that participants see their suggestions immediately and can discuss them with everyone else.
• Simple notation: Graphical models of business processes with UML activity diagrams, EPK, BPMN or flow diagrams each have their own notation. Even if these methods have relatively few elements, someone who isn’t familiar can feel inhibited to ask questions. For story mapping, you only need to know a few things. Time flows from left to right, and user stories and activities are represented in different colors. That’s pretty easy.
• Work planning: Story maps and product backlogs are two ways of looking at the same thing: the user stories that are to be implemented. However, they serve two different purposes. Story mapping analyzes business processes for completeness, sequencing and priorities, whereas the product backlog controls work planning. Some claim that the story map also serves as a “map” for the product backlog, because it gives the backlog a topically organized, multidimensional structure. In this way, the story map can even be more useful than the backlog for work planning. For example, all user stories that contribute to a particular outcome can be planned for the next sprint. User stories can be transferred 1:1 into the sprint backlog. Here it’s not necessary to translate between the project structure plan and the work breakdown structure, or work packages, as in classical project management. The story map IS the project structure plan and the user stories ARE the work packages.

The agile world didn’t invent business process analysis, but modified it so that it’s easy to understand, seamlessly integrated with work planning, and users can participate. Story mapping is even fun.

For more reading:

User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly 2014

https://jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf

Learn more about Dr. Andrea Herrmann at her website: http://www.herrmann-ehrlich.de/