In this article, we look at a very specific technique that will make the work of the product owner easier and offers great benefits to the whole team: User Story Mapping. What is that? And how can I adapt the method to my specific project?
What is User Story Mapping?
Jeff Patton describes the idea of a user story map in his book "User Story Mapping". For him, there is an elementary reason to use this technique in agile software development:
"Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product."
A story map is a visualization method that helps to take user needs into account while maintaining an overview of the backlog. Using the method improves the mutual understanding of the overall process within the team. But how does the method work?
Important terms are epic and user stories. Epics are collections of user stories and describe requirements for the software to be developed in higher abstraction levels. User stories, in turn, describe the individual steps the user needs to complete to finish an epic.
For a user story map, individual, rough work steps are recorded in epics. The steps required for completion are described in brief, concrete user stories (fig. 1).
Figure 1: User Story Mapping (according to Jeff Patton)
By means of such a visualized user story map, the requirements can be prioritized two-dimensionally, which leads to a better overview. The horizontal reflects the individual tasks (time), while the verticals show the corresponding work steps to these tasks (detail level).
And why the whole thing?
If such a story map exists, the development team can optimally assess the planning of its work with regard to the delivery of the software. During development, progress can be matched to the story map at any time to reveal discrepancies and react quickly. This display mode is especially suited to throw a common view of the project’s current status at the beginning of the sprint plannings.
In summary, user story mapping can help
- to find out what should be developed first,
- to the keep an eye on the scope,
- to plan better,
- to promote iterative development,
- to prioritize and maintain the backlog, and
- to visualize the project progress.
Individualization of the user story map
Based on Jeff Patton's method, I adapted the user story mapping for our project in my role as a product owner. I organized the column of the user map so that they no longer reflect the different epics, but the individual sprints. This allowed me to demonstrate to the customer which tasks should be carried out at which stage of the project. So I moved the temporal component completely to the horizontal axis and moved all tasks and efforts into the vertical.
I summarized the different epics and user stories as follows: Under each sprint are several epics, which also contain some of their user stories. In this case, I identified how much effort should be put into each epic or user story per sprint. Behind the respective epic names were the current expenses in so-called storypoints, which should be operated in the respective sprints, as well as the remaining expenditure of each epic (fig. 2). When the stories and requirements were not defined exactly, a +x signaled the still open, not estimated expenses.
Via this representation, I could always determine which tasks each sprint contained and when they would be available for the customer. I wrote the development capacity of the team behind the sprint name, so we could determine the scope in the planning. Usability activities as well as undefined requirements were marked in the story map (fig. 2). I also was able to integrate milestones, e.g. a pending release, into the story map.
Figure 2: Example of an overall sprint planning
In addition, I introduced small icons with which I could represent the progress of the development team. So I gave the team in each sprint review an overview of which stories had been completed and which were not. Unfinished stories were moved into the next sprint. This presentation was especially popular with the customer, since the story map could now also serve as a release plan. Since our scrum board represented the most relevant tickets and their prioritization from the story map, we were always able to work with this board during the development and in the meetings with the customer in order to take a closer look at special informations (eg concrete user stories).
By customizing the original idea of the user story mapping, I was able to give the team and the customer a clear overview of the current project at any time - without having to create complex release plans and feature lists.
Try it by yourself!
If you're looking for a way to arrange your user stories and project release plans as well, feel free to download our sprint planning template or contact us.
Comments