No one could argue that a team in charge of developing a product has the best shot at success if they position themselves from the perspective of the product’s target users. It’s only natural. Thinking like your intended audience can help you shape a better development strategy, which ultimately will decide which features to include, which to get rid of, and how to build the whole thing.
In general terms, that’s the approach software development companies have been using forever. Of course, there is more to it than this, but at its most basic level, the process is all about aiming for what research tells us about the target audience. But if you get into the process details, you’ll quickly notice that there are plenty of things to be defined.
One of the most important is deciding how to leverage the information you get through the initial research, especially the one focused on the potential users. How can you use that data to get in the audience’s shoes? The traditional answer is fairly simple—by developing user stories and consolidating them in a product backlog.
A product backlog is the common practice for any agile-driven team, as it provides a list of features and activities that engineers need to do to build the final product. In that sense, a product backlog communicates the project’s requirements and vision and organizes the whole work ahead. It has been that way for years and it has served us all very well.
However, using product backlogs has its limitations. In fact, those limitations were the reason why Jeff Patton, an agile enthusiast, started seeking an alternative way of organizing that user information back in 2005. What he came up with forever changed how we develop software—he created the Story Mapping approach.
From Flat Product Backlogs to Story Mapping
Before moving forward, it’s important to clarify what we mean by user story, as this is a key term for Story Mapping. Basically, a user story is an informal description of the features of software, written from the perspective of the user in plain natural language. It usually follows the same structure:
As a [type of user], I want to [action] so that [benefit].
Traditionally, business analysts, project managers, stakeholders, and product owners all describe what they want the software to do by using the structure above. The result is a list of features that are then combined into a product backlog, a list of the user stories the team already produced.
The problem with that resulting product backlog is that it’s flat. In other words, it doesn’t provide any context to the project, as it’s just a list of things the development team should build. Without the necessary context, engineers don’t have many details about what they are building, how they are expected to do so, or even why they are doing it. Some of the common problems of those flat product backlogs include:
- No user story prioritization or hierarchical prioritization without further context might cause confusion and priority conflicts.
- No big picture, as each user story in the product backlog doesn’t organically integrate with the rest to describe the product as a whole.
- No user journey, as the more general activities are decomposed into smaller pieces that end up feeling more like development tasks than user activities.
Naturally, there are methods and practices to deal with those problems. But there’s also Story Mapping, which is an alternative approach that doesn’t have those problems, to begin with. That advantage is what turned Patton’s approach into a highly popular technique for strategizing product development.
What Is Story Mapping?
Basically, Story Mapping is the practice of producing user story maps. As its name implies, a user story map is a way of mapping out user stories and other backlog items in a visual manner. In a user story map, all items are organized into 2 dimensions, in which the vertical axis denotes priority and horizontal represents sequential steps of the users (aka the user journey).
Story maps have specific structural elements, including:
- Backbone. This is the foundation of the map and is made up of epics, which describe general user interactions with the product (for example, when the user searches for something through the search board). These interactions are placed horizontally, as they show the sequential steps a user needs to take to carry out a specific action.
- Stories. User stories are arranged in both axes, because some have higher priority (so they need to be placed in the vertical axis) or because they tell a user journey (which is why they are organized in the horizontal axis). For example, several stories that describe the “search epic” could include “basic search,” “search filters,” and “advanced search.”
- User personas. These are fictional representations of the people who will carry out the activities described in the user stories. Personas basically describe who the potential users are and how they’ll likely interact with the software.
- Nice-to-haves. While not mandatory, the nice-to-haves inform the user story map by completing it with ideas that aren’t required but that can add a differentiator to the product later on.
Given the comprehensive nature of the user story maps, it’s best to build them through a collaborative effort. That means the product owner or the engineering manager aren’t the only ones responsible for it. The creation of user story maps should also include business analysts, project managers, stakeholders, product owners, and even engineers, all of who can add valuable user stories and different perspectives on how to prioritize them.
In practice, that collaborative effort proves to be very beneficial, as the whole team provides their insights and understands the motivations and goals behind each proposed user story. In short, building a user story map as a team provides a full picture of the project and helps better communicate the expected results of the work ahead.
Why Use Story Mapping?
By using the structure I described above, a team can overcome the limitations of the flat product backlog and provide a clearer path to the development. In fact, a well-organized story map provides several benefits, including:
- Clear prioritization of user stories as they are placed in the vertical axis. Also, all user stories display their connections, which improves the visibility for each one of them as well as how they relate to one another.
- Inclusion of the user journey, thanks to the sequential steps located in the horizontal axis. This allows the team to easily understand each story and the place it takes in an overall sequence of actions.
- Flexible product vision that can be expanded as new requirements and goals arise. On one hand, it helps the team to implement the user stories on a technical level. On the other, it provides enough agility to accommodate most modern projects.
- Improved communication, mainly because the story map is created by several team members who can align themselves behind the same ideas, vision, and objectives.
Is Story Mapping Better Than Using Product Backlogs?
While I can’t say that one approach is better than the other, I can affirm that story maps have some neat benefits. The main one is that by creating a story map a development team gets a clearer picture of what they are about to build. That clarity comes from the visual form of the map over the somewhat abstract nature of the product backlog.
With that being said, I’m not bashing product backlogs. A good product manager can easily come up with a solid product backlog that contains everything developers need to build the software, including features, timelines, sprints, and releases. However, Story Mapping has a collaborative nature at its core, which can produce further benefits.
What you should take from all this is that Story Mapping can improve your approach to product development. It can help you tackle MVP development and complex projects, all while improving the communication between all the team members. In and by itself, that comes to show why Story Mapping is relevant to development teams—because it helps different team members bond and align themselves over shared goals.
