How to create clear, collaborative user story maps

What user story maps entail

A user story map creates a structured backlog with enough detail for software teams to work -- and enough detail for marketers to promote the product of that work.

To understand the map, it helps to walk through an example. This sample story map, courtesy of Steve Rogalsky, director of product management at D2L, displays a design that reflects everything from larger concerns to small, specific ones. Focus areas are at the top of the user story map for feature development. Those areas break down into features, in light blue on the sample map. Below those features are the yellow pieces of the map, the user stories -- teams execute development efforts for these items. Those stories are ordered by priority and grouped into releases.

Ultimately, the finished user story map should translate stakeholders' vision for the software into a roadmap to build it.

How to create a user story map

In theory user story mapping is easy: stick the right people in a room, and, an hour or two later, out pops a map. In reality, without structure, the software team members would likely argue about the meaning of the core features to include on the user story map. The map makers would be in danger of creating a user story map where everyone has a shallow agreement, with a severe and expensive misunderstanding at hand.

Instead, follow these four general guidelines to create a user story map, then customize them to fit your team and a given project.

Lay out phases. A user story map has two organizational elements: the phases the map makers group vertically, and the features they lay out horizontally. Try splitting the work into phases. Perhaps each phase represents three months of work, a press release and an update to training materials. That setup gives the people involved reasonable assumptions about ship dates for the software. However, a software development team does not have to split work into phases. A continuous delivery team can pull stories one at a time, moving left to right, then start over again with the next story.

Estimate features. Many teams have assumptions about the timing, focus and priority of features when they go into a software project. For example, team members might expect to focus on search in Q1, then mobile capabilities in Q2. A product marketer should know these expectations before work begins on a user story map.

Start with a clear vision. Features must be clear enough to everyone on the team that it prevents shallow agreement. Track first-time quality, a measure of the amount of changes and misunderstandings in the software that testers or customers uncover. If everyone is on the same page and there is no groupthink, then map those user stories. If not, try product visioning meetings to discuss and refine features. Map makers don't need to detail features exhaustively; everyone just needs to understand the goal and broad work effort.

Get physical. Once it's time for the meeting, get a corkboard or whiteboard. Use colored masking tape to create an outline for the user story map; orient phases to run vertically and position focus areas horizontally. If you don't know what to use as focus areas, try an affinity mapping exercise, where the map makers create features on sticky notes, and then organize them into groups. The groups represent the software's focus areas.

How to conduct the meeting

Have a person with product knowledge act as the neutral meeting facilitator. Consider a product owner who has worked with the team before, or a subject matter expert. This person should have listening skills and the ability to adjust rather than drive discussion. Their mission is to keep all interested parties on topic and ensure no voice overpowers the others.

During the meeting, stakeholders create cards that represent micro-features, and then put them on the board. Focus on the order of the microfeatures and the phase in which they should appear. If there is disagreement, settle it with dot voting, in which participants support something with varying degrees of commitment. Don't default to the opinion of the highest-paid person in the organization.

Teams have plenty of graphic planning tools to choose from, and they often transfer the physical board to these virtual versions. It's tempting to start with a digital board, but physical media helps people visualize the work in progress better than the same information on a screen. For example, a corkboard only has so much space, so it's immediately obvious when the team has jammed too much into one area. Physical mapping also connects with the project members on various levels -- they discuss, look at the cards and touch them. Of course, if your team is distributed and must have online meetings, use a virtual option.

The user story map that comes together in this meeting is more like a first draft than a published manuscript, but it ensures a shared vision and common vocabulary on the project.

Who should be in the meeting

Most organizations want to discuss the vision for a software project among the company's high-level development. Commonly, at user story mapping meetings, you will find project managers, Scrum masters, designers and product owners. A development manager might be involved, as might a lead or architect when management is disconnected from the technical side.

Ensure there's a representative in the room with broad knowledge of the product and the customers' use cases. This person should be able to dig into the details, like a software tester. They will drive discussion about what the feature really is and point out inconsistencies or lopsided approaches in the plan. That knowledgeable worker's role isn't to play devil's advocate to the project manager or designers; they're there to contribute meaningfully to a better plan based on realities in the development work.

Experts suggest the user story map makers range anywhere from three to seven people. These groups can work without a facilitator; Rogalsky suggests other ideas to improve outcomes along with his sample map.