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.
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:
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 or spikes, 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)
 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)
 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.