Step 4: Story Map

This chapter describes the fourth step in the framework, breaking down the previously prioritized opportunities and improvements in a process called story mapping.

To actually develop the prioritized opportunities and improvements they have to be broken down into work items, which are small and precise enough to be implemented by development teams.

To achieve that, we create what is called a user story map. Based on the prioritized list of opportunities/improvements from the previous step, each of them is now broken down in to actionable work items. (See schematic below)

At the top (shown in blue) we have the user’s steps when interacting with our product (taken from high level product flow) and on the right (turquoise & red), we have the opportunities/improvements A, B, X and Y, that we identified as our top priority items earlier.

Now ordered by priority, we can start breaking down each of these opportunities/improvements into actionable user stories, that make that opportunity/improvement come to life.

Example:

Let’s assume ”Opportunity A” of our pizza delivery app would be “Order Pizza” we now start breaking down what development efforts our teams would have to do to achieve that. Collaborating in cross-functional teams, they come up with the following user stories:

• User story: As a user, I would like to select my pizza directly from the menu, so I don’t have to remember their names or numbers when ordering
• User story: As a user, I would like to be able to review my selected food in a cart-like-view to prevent giving out wrong orders
• Spike (shown in pink): At this early stage, we don’t accept digital payment methods – but as easy payment is identified as high priority, we need to research what payment providers we could use in the future and how much effort that might be.
• Nonfunctional requirement (shown in green): The servers have to be able to take very high peaks of users ordering simultaneously, as the football season is coming up, and at each game, orders usually rise up to 10x as high as normal.

As shown in the example, breaking down opportunities/improvements can produce various types of requirements. These might be user stories, but could also be nonfunctional requirements[1] or spikes[2], where more research or experimentation is required.

This step is highly collaborative, so we strongly recommend doing this in a physical space, or with adequate online collaboration tools, like Mural, Miro or similar tools.

Within each opportunity/improvement, the vertical position of the requirements represents priority.

During requirements elicitation, visually mark dependencies between stories with arrows. This is especially important as dependency management is only possible, if they are transparent and known to everyone.

It’s important to understand the story mapping process not as something we do once, but rather something that we regularly repeat to select the most valuable things to do next based on the currently available information. (See also story mapping & estimation meeting)

[1] Nonfunctional requirements (NFRs) are requirements, that describe general requirements, like performance or stability. These cannot be directly developed, but rather create the boundary for other requirements. For example, if we have specific performance targets, all development work has to make sure, that the targeted performance is possible. Depending on our agile process, these NFRs usually are placed as some sort of quality or test criteria to make sure all other work complies with these (i.e. called “definition of done” within Scrum)

[2] Spikes are work items, which aim to reduce uncertainty around a specific area. For example, a new technology has to be evaluated first, to assess if it should be used within the project. This assessment work is called a spike. A spike can result in adding more work, as more is learned during evaluation or experimentation.