Recently, I participated in an agile business requirements training given by my colleague Thomas De Vries and Patrick Steyaert. One very interesting technique that they highlighted is story mapping. In this post, I will explain how to apply this technique and highlight the advantages compared to traditional techniques for eliciting requirements.
When multiple people work on a project of some size, there often is no shared understanding on what they are actually working on together. A famous story illustrating this is the one of the blind men and an elephant. A story map created together with the stakeholders at the start of a project counters this well-known problem by offering a visible and holistic view on the scope of this project.
Organizing a story mapping workshop
Set the scope of the workshop
Once you have prepared the outline of the project, you can identify the key stakeholders that should participate in the story mapping workshop.
Let the participants write their own user stories
Ask each of the participants to write down his or her business user stories on post-its. This is a very natural process, as the participants are actually asked to write down the tasks they (want to) perform. (In my previous blog post, I explained how user stories should indeed express business tasks.) The result so far is an unstructured bunch of user stories.
The next step is to let the participants structure all the user stories, in a logical (chronological) order from left to right. Tasks (user stories) that could take place more or less simultaneously are placed above each other. Then the participants should identify the main activities that are completed via the tasks they have defined. These activities can be written on post-its of a different colour than the ones containing the user stories, and placed above the user stories.
The image below is an extract from the course material, providing an example of (a part of) a story map.
What's in it for you?
A story mapping workshop allows to elicit business requirements in a few hours, directly from the key stakeholders. After the workshop, the participants understand the entire project scope rather than just the part in which they are directly impacted. In addition, on the lowest level of the story map, the translation to application level requirements can be added. This offers a great help in prioritizing system stories as it is visualizes to which tasks and activities a particular system story contributes.
Eager to learn more about story mapping or you want AE to host a user story mapping workshop to help your teams grasp project scope? We would love to help.