Structuring a product backlog can be helpful to keep an overview of the user stories and see the bigger picture. The blog post story mapping and/vs process maps from Shrikant Vashishtha describes how you can map user stories on a process map. He compares the process mapping approach for structuring user stories with story mapping from Jeff Patton.
In Scrum, the product backlog is used to manage the product needs. For a large product there may be many user stories in the backlog, which can make it difficult to keep an overview and see the bigger picture. Also when you have many user stories, a similar thing can happen with the sprint backlog of the team:
(…) many times, as you look at the card-wall (Scrum Board), things are not very clear to you. Card wall may look like the mesh of user-stories with statuses in To Do, In Progress or Done. However some of the bigger questions are not clearly answered by just looking at user-stories.
Shrikant suggests to do process mapping to to structure the product backlog and visualize user stories:
How about having a pictorial view of whole business flow as a process-map, identifying the user-stories (work to be done) in it?
The process maps mention the IDs of the user stories that are used to implement parts of the process. Looking at the process map you can see which user stories are needed for a business flow, and if you use colors you can make the progress of the business flow visible.
Another approach to structure a large product backlogs is story mapping, as described by Jeff Patton in his 2008 article the new user story backlog is a map:
Arranging user stories in the order you'll build them doesn't help me explain to others what the system does. Try handing your user story backlog to your stakeholders or users when they ask you the question "what does the system you're building do?" For my money, trying to understand the system - the whole system - is the difficult part of software development. One of the most common complaints I hear from Agile teams is that they lose the big picture - that is if they ever had it in the first place.
Jeff explains how story mapping helps to communicate the big picture:
I find a story map hung as an information radiator becomes a constant point of discussion about the product we're building. When the project is running, it becomes our sprint or iteration planning board. We identify or mark off stories to build in the next iteration directly on the map. During the iteration we'll place just the stories we're working on into a task wall to managing their development - but the story map lives on the planning wall reminding us what the big picture is, and how far we've come.
Previously InfoQ wrote about how story mapping helps to structure a product backlog in story mapping gives context to user stories:
A story map is two-dimensional, indicating the priority of stories, as well as their relation to each other and the larger goals of the users. The map helps the team to understand how stories fit together to form a releasable product.
After having describes how process mapping works in story mapping and/vs process maps, Shrikant Vashishtha continues his blog post by comparing process mapping with story mapping. He describes how a product backlog looks with story mapping:
The idea of story-mapping is to groom Product Backlog in such a way that you have “big stories” (termed as “user activities”, epics or features also) at the top of map. These big stories are divided further into user tasks (something that someone does to reach a goal).
Shrikant gives some drawbacks from using story maps:
Story maps are great information radiators. However they may require big space to capture stories of entire release. Also story-mapping doesn’t necessarily provide information on the linkage between stories or how those epics/user-stories are orchestrated together to reach a business goal.
Where it becomes difficult to keep an overall view with story maps, Shrikant suggest that process maps can help since they do not show all the details:
Instead of having all stories on board, you instead put a big poster of process map embedding the user-story identifiers in it. Process-map in itself is also a narrative and helps people to come on the same page.
He concludes by explaining that you can use both process maps and story maps to structure a large product backlog:
(…) it may look like that process maps and story maps are completely different concepts to solve the same problem but they are not. They are tools to bring more clarity on the board. Depending on the context, they can be used to complement each other.
In the blog post user story mapping—goal-driven backlog development, Scott Sehlhorst gives an overview of story mapping. He start by stating what the purpose is:
User story mapping is a technique for assuring that each release or iteration makes the product tangibly better. (…) User story mapping forces you to explicitly understand the processes that users follow or will follow to solve problems and the value-chain or workflow by which these users achieve their goals.
Scott explains how story mapping can be done, and which benefits it brings:
With user story mapping, you organize the user stories or tasks that users perform into groups that identify which stories are collectively required to deliver value. This is a powerful technique for assessing the completeness of your requirements. It also gives you a tool for assuring that each release or iteration adds value by enabling a user to solve, or more effectively solve, a problem—avoiding a delivery that only solves half of a problem.
Do you structure your product backlog with story maps or process maps? Do they help you to keep an overview and see the bigger picture?