Story Maps as a Tool for Communication in Different Directions


People who are responsible for creating and maintaining digital products in an organisation often have to communicate in different directions. Each requiring a different level of detail.

Basically there’s two directions in which product managers have to communicate:

  1. Specific/Detailed: You need to specify your product increment very detailed for designers and developers to make sure, everybody has the same understanding about what to build.
  2. General: You need to harmonise with other people in your organisation who create product increments on a more abstract level in order to work towards the (hopefully) common product vision and discuss priorities.

In my experience discussions about features, scopes and priorities often disconnect with the original goal of creating a product for user needs. I’d like to propose my framework, based on user stories, for handling this complexity in an organisation.

User stories have become increasingly popular due to the rise of agile methodologies and particularly as an important artefact in Scrum. The main purpose of a user story is to maintain user centricity during the development process. User stories are more specific than scenarios but include the user perspective in opposition to plain requirements. That’s why I think user stories are a good artefact to build your communication on.

Let’s have a look at the two directions in which product managers have to communicate and how story maps can help them.

1. Specific/Detailed

Imagine you want to integrate Google Analytics data into a Content Management System (CMS). You could write an abstract user story like this:

As an author I want to see web analytics metrics for my content in the CMS in order to determine the performance of my content.

This kind of story is not detailed enough for a developer to implement it. So you typically break this kind of high level user story down into various more detailed stories:

  • “As an author I want to see page impression…”
  • “As an author I want to compare different channels…”
  • “As an author I want to view metrics for a certain timeframe…”

The process of splitting user stories into various smaller, more detailed user stories can produce a very long and flat backlog of user stories. Even though a backlog like this might be a good source for developers to get good specifications based on user needs, it doesn’t tell you much about which user stories depend on each other and how user stories are connect through user flows and scenarios. To understand the whole thing you’re building, a flat backlog might not be the best tool.

In order to better visualise a new product increment, I use story maps. They typically show the user flow from left to right and the importance of features from top to bottom. The black boxes stand for subsets of features (or “epics” in Scrum). The white boxes represent actual user stories in your backlog.

Example Story Map for a feature set, ideally showing the user flow from left to right and importance from top to bottom. The green line indicates the scope of a minimum viable product

A story map for a certain feature set helps determining what to build in order to ensure a viable product. You can use lines to mark the scope of the minimum viable product and future releases. This kind of story map is a useful tool to discuss priorities and the scope for future releases with your team. Missing pieces in your specifications will become obvious pretty soon by having a look at a story map.

Story maps improve a team’s understanding and feeling for a product increment. The benefits of a well structured story map are almost always worth the effort.

2. General

In my experience, the scope of one story map roughly equals the capacity of one sub-team (product managers, developers, designers). But when organisations grow, there’s usually more than one sub-team working on a product. At this point, product managers have to synchronise with each other in order to work towards the common product vision and discuss priorities.

Having a story map for each feature set is already a good basis for discussing the big picture. In my opinion, story maps are better for giving other people an idea about what you’re planning to build than backlogs in excel or flat lists in project management tools. The main benefit of story maps is that they are based on user needs, something that often gets lost along the way.

If you want to have an overview about all product increments or if you need to scale broader, you can combine various story maps into one product or release map:

Summary

User stories are a good artefact to manage requirements based on user needs. However, a long list of user stories doesn’t tell you much about which user stories depend on each other and how user stories are connect through user flows and scenarios. Consider using story maps to better visualise product increments for other people in your organisation:

  • Designers and developers get a better understanding about what to build by looking at a visual & structured story map rather than having a flat list of backlog items.
  • You can easily give other people in your organisation an idea about what you’re planning to build by showing them a story map. This might help you communicate with other teams.
  • I would go so far as to say that story maps are a good tool to initially discover the scope of a product based on researched user problems or scenarios.

After all, Backlogs are for communication, not for delegation. Using story maps might help with that.

Further Reading: