User story maps are an incredibly valuable tool for creatively developing and overseeing the vast number of ideas and features for a product. They are excellent for breaking free from the one-dimensional limitations of a backlog and for discussing and prioritizing stories along the development process ("flow"). The icing on the cake is that the goals of the user roles involved always remain in focus.
Jeff Patton is considered the pioneer/inventor of the story map. He has also written an excellent and engaging book on the subject (Patton, Jeff; User Story Mapping; O'Reilly Media). The book is far from being a technical guide on how to create a story map and which notation to use. Rather, it demonstrates how a team (and its stakeholders) can use the story map to design, discuss, and prioritize a product in a user-centered way at different levels of detail.
The three levels
In practice, it has proven useful to consider three different levels. However, this is by no means an ISO standard or anything similar. If it makes sense in a given context to subdivide one or more of the levels – just do it.
The User Activity describes the activities a user wants to perform with the product. For example, "send an email," "post a photo," or "generate an interest statement." A helpful mnemonic is to imagine that the user can take a coffee break after completing an activity. Each activity has a corresponding user role. It's important to note that a third-party system can also assume the user role (analogous to the actors in a use case diagram). These actors, of course, cannot take a coffee break! :) A dedicated team workshop is recommended to identify as many people and systems involved with the product as possible, thus helping to identify these roles.
The second level – the user tasks – tells the story. Patton refers to this as the "backbone" or the "flow." This includes the individual steps that must be taken to complete the activity. Examples:
- Send email: Open a blank email, enter the recipient, write the text, add an attachment
- Post a photo: Select photo, apply filters, decorate creatively, submit
- Create interest statement: Prepare account data, calculate interest, send data to output system, save PDF in archive
The tasks should be placed in the typical order of execution. Often there are several possibilities for this. Discussing this is another valuable resource for identifying undiscovered tasks and understanding the product.
The third level records the details of a task. Many tasks can be completed in different ways. These alternatives are the potential user stories. Example:
- Enter recipient: Type recipient, select recipient from address book, suggest autocomplete, CC recipient…
- Select photo: Choose photo from camera folder, upload photo, choose photo from OneDrive
- Calculating interest: Find the interest rate, take preferential interest rates into account, deduct withholding tax,….
collaboration
A user story map thrives on collaboration. The map is developed, supplemented, discussed , and prioritized jointly by the team and stakeholders . If a physical map is displayed in the office, it can be easily customized. For example, colored stickers can be used to represent stories with dependencies, the logo of the responsible team, or symbols indicating complexity.
Anyone who has already worked with physical user story maps also knows about their weaknesses:
- The map size increases very quickly and the walls are limited.
- Moving sticky notes around is very tedious, especially at the beginning when not all activities or tasks have been identified. And what do you do with the sticky notes that are always lying around on the floor first thing in the morning?
- Eventually, the stories are entered into the digital issue-tracking system and the one-dimensional backlog becomes the basis for discussion – the overall view is lost again.
- Distributed teams do not benefit from this valuable technology.
To eliminate these weaknesses, we, together with our colleagues from Swarmit , searched for tools for digital story maps and described them in detail in this article:
How to start?
To learn about User Story Maps, the morning routine exercise described by Patton in his book is ideal. You can read about the exercise here or experience it directly in our course "How to User Story".
To get an overview, Patton's Quick Reference Guides and presentations – as a supplement to the book – are highly recommended.
Can we support you in conducting the morning routing exercise or in creating a story map for a new or existing product? We'd be happy to help you learn about and apply the user story map. Contact us for a free consultation or find out more about our training offerings.
Let's go!
The most outstanding advantage of the story map is its two dimensions. While the flow tells the story of the tasks to be completed, the three levels delve deeper into the details. Thanks to these concepts, the overall perspective is always maintained during discussions, and you can flexibly switch between the levels. This makes a story map suitable for almost all types of software products – although sometimes a little imagination is needed for the user roles, activities, and tasks (tip: choose user roles that interact as directly as possible with your product. If your system is a data provider for System X and the 'real' user works with System X, the user role "System X" is probably more suitable for you).
Example: Story Map for the course “How to User Story”
It might seem that story maps are only suitable for new developments. However, they also offer a wonderful framework for (re)gaining or documenting a comprehensive overview of existing systems. By considering which tasks the system performs and which functions support them, you not only regain the context (if it has been lost or is only remembered by a select few) but also have a tool at hand to identify new, beneficial features.
Give it a try. If you like, feel free to share your experiences with Story Maps in the comments.
Good luck!
Yours sincerely, Benjamin Wyss
