In this installment, we explore one of the most common difficulties of agile teams: Backlog overflow and the struggle to the maintain a mostly flat backlog.
It is now a common practice in Agile software development to implement user story mapping, but it hasn't always been that way. The typical method teams use to prioritize product features is to sort them in a product backlog. Since the product backlog is structured similar to a shopping list, it is filled over time and inevitably becomes long enough that the team will feel overwhelmed with the amount of stories it has to implement and which items to prioritize. This backlog is also known as a flat backlog.
Product backlog in a visual form. Image from Pexel
The challenges posed by the flat backlog is what motivated Jeff Patton to create the concept of a user story map. The user story map is a visualization of the journey a customer takes with the end product, which includes the activities and tasks they would typically complete. It prioritizes a customer-centric approach to manage the product backlog.
Example of a user story map
Compared to a traditional product backlog, building out a user story map provides multiple benefits. Here, we will highlight the major problems that user story mapping solves.
Compared to a typical product backlog that is vertically ordered, a user story map is a view with both a vertical and horizontal axis. The vertical axis denotes priority, while the horizontal axis represents the user activities that the end user takes as he uses the product, which helps provide context for when you start organizing the deliverables. User story mapping gives a holistic perspective to think about how things fall in place. The story map’s organization ensures that the emphasis remains on the customer’s journey and not on the technical implementation approach.
Building out a user story map helps teams prioritize the important requirements first. You are able to discuss with your team what items matter most from an end user's point of view and rearrange your map to reflect that. Note which features need to be prioritized and what the expected deliverables are for the product’s first release. Don’t be afraid to defer the features that have lesser importance to the next release or even remove features that are unnecessary. By planning out release dates and assigning tasks to specific members, you are able to break down large tasks into smaller, specific ones and deliver code based on the prioritized features.
A user story mapping workshop is usually conducted at the beginning of the project with the sole purpose of creating a shared understanding amongst the team of who the customers of the product are, and to laser in on the stories that provide the most value for the customers. This helps stimulate better conversation between the product and IT teams which will result in a user story map that is both refined and easy to understand. Furthermore, involving a stakeholder is encouraged in a user story mapping workshop as it helps facilitate the dialogue between the team and the customer which makes it a lot easier to understand the desired output.
While a user story map is effective, it also comes with several caveats. For example, since user stories are written in an informal and more natural language, the user stories may leave out too many details and be considered too vague for the development team to work with. Also, the user story map has to be visible to all team members to be truly effective. While a physical user story map is favored during backlog grooming sessions, projects with remote teams will have to resort to using online tools to be able to view their story map conveniently. One such tool is Story Mapping for Jira, which provides a free version for users to have a feel for user story mapping. Story Mapping also comes with a Pro version which brings substantial improvements over the free one.