User story mapping is a powerful technique for requirement gathering and project backlog management. If you were ever in a position where your team has a rough idea about what needs to be done, but the work is complex and you are not sure how to approach it and break down into activities, and also there are many questions that need to be discussed before you can do this, than user story mapping is definitely a technique to try.
The basic idea is very simple. Even though there are different theories on how you can make maps, I personally prefer to start with the most simple variant, and then gradually build up based on the project needs.
In short, the session will look like:
- You prepare a board and stickers (physical, virtual - whatever is team’s preference).
- The story is told, from user perspective, which describes flow of how software will be used.
- The main steps of the story flow are written sequentially and separately (blue stickers on the picture).
- Below each step then you put all elements/activities/user stories related to this particular step (yellow stickers on the picture).
User stories should be ordered top-down in accordance priorities. If this is the case, a product owner can easily slice the map by placing a horizontal line, so everything above the line represents MVP or something you need to deliver during an iteration or for a release.
You don’t need anything else but basic understanding to put user story mapping in practice. Easy to understand, a bit more complex to master. But in the same time, your team will immediately gain great benefits of using it.
One of the benefits of 2D grid, in relation to the typical flat backlog, is that visually it is much easier to grasp the project requirements, and notice open questions and dependencies. Visual thinking is common in approximately 60%–65% of the general population, so the most chances are that this type of representation will be the most suitable for your team too.
Secondly, this will definitely be a very efficient way for both the team and stakeholders to create a mutual idea about the overall picture of the project, both from the business perspective, but also from the perspective of project implementation. The common understanding of everyone involved is a precious asset to any project.
Besides that, prioritisation is becoming simpler. It is very easy to prioritise and in the same way make sure that you indeed take stories that will compose at least a minimal viable solution.
Finally, maybe the most important benefit is that this will boost communication and discussion, and reveal questions of all participants in early phases of the project, which will lead to more quality and faster product backlog creation.
Especially interesting experience is practicing user story mapping on a back end project, and my team discovered this during a recent session we had.
In the beginning I was a bit reluctant, because the application of this technique is typical for front end projects. For front end this is natural, because everyone can easily imagine stories of end users, and project this on a map.
Thinking about back end, the story needed to be about how two other complex software modules will use what we need to make. In other words, our “user” was pretty abstract and sounded a bit complicated for simply describing its stories by putting stickers on a wall.
Surprisingly, working on the map was even more beneficial and engaging than it would be is we would tell the stories of end users. The reason is that mapping back end algorithm was actually the perfectly natural flow of thinking for people used to programming. Therefore, the team got completely interested and involved in maps creation, many essential questions were raised and clarified, and this session resulted in a map that now represents extremely useful backlog both for product owner and development team members.
Besides that, after user story mapping sessions were finalised, the team already had very solid idea not only about what needs to be done (as it would be the case after the typical mapping session for front end), but in the same time how they will do it.
Thanks to the great team and this great technique!
