Five common story mapping mistakes

tl;dr:

I suspect if you’re reading this, you already know what story mapping is. I’m proud of that. If you don’t know what it is, this article will refresh you with the basics.

But what this article is really about are some of the common mistakes I see people and teams make when they create and work with story maps. In case you don’t want to read the article, here they are:

1. Losing the story
2. Getting lost in the details
3. Worrying too much about flow, branches, and what-abouts
4. Mapping the whole product when you’re trying to add a single feature
5. Not anchoring releases on an outcome

If you know about all those common mistakes, you can skip the article. If not, read on.

Special thanks to Shipra Kayan from Miro. She asked me to write this stuff up in support of Miro’s Distributed ‘23 conference. If she hadn’t asked, I wouldn’t have done it.

What is Story Mapping?

Story Mapping is a simple way to break down a big story simply by telling it. The shape of a map is simple. Left to right it tells a story from users’ perspective. Top to bottom it decomposes that story.

Simple.

If you have a new idea for a feature or capability to add to your product:

1. Identify the people/users in your story
2. Identify the beginning and end of the story
3. Tell the story step by step – where each step is what people do to use the feature.
4. Break down each step into sub-steps or details. Think about options and alternatives.
5. Play “good-better-best:” What’s a good enough solution? A better solution? The best possible solution?
6. Now that your map is filled with options and details, slice the map into a series of small successful solutions or releases.

If you want to learn more about the practice of story mapping, you should buy a book, read an article, or download a quick reference.

1. Losing the story

I see lots of people use a map shape to break down features. They know they need to build many features. They may even know who uses those features. So, left to right they list the features, and top to bottom they break those features down into smaller buildable parts. You know you’re looking at a feature decomposition like this when every card has a noun, or description of a thing, on it. While that may be a useful map, it’s not a story map.

Instead, start by identifying the person or people in the story, choose a beginning and end, and then tell me a story of what they’ll do that cuts through using those features. You’ll find every card or sticky has a short verb phrase on it – a step.

2. Getting lost in the details

Story maps have an “altitude level.” That is every step that people take can be high level like “get ready for work,” lower level like “make breakfast,” or even lower level like “make toast.” If you break every step down to a low level, your map will have potentially hundreds of cards – way too much detail to make sense of. You’ll suffer what some call “map shock.” Try to stay at a useful level of detail.

Avoid going into detail prematurely. Make sure you know the beginning and end to your story before you start. Then, get from beginning to end before dropping down into detail. Some people fall into details early in mapping and never get back out. Think “mile wide, inch deep” to start with.

3. Worrying too much about flow, branches, and what-abouts

When telling a story you’ll likely come to places where users perform actions in a different order. I’ll often see arguments break out about what the right order in the map should be. Remember, you’re building a map for a product that will get used by a variety of different people. You’ll use this map to tell all of their stories – and their stories are different. Choose a typical flow left to right. Then, when retelling the story say “people typically do this, then this, then this…. But some people do this, then jump over to that, then back to this.”

When you tell a story you’ll inevitably come to a branching point where your user could do step A or B. And, if they do step A, a bunch of other steps follow. If they choose B, a bunch of different steps follow. You may be tempted to turn your map into a flowchart. But don’t. Keeping it flat allows you to use the vertical axis for decomposing options and prioritization. Try bringing things up to the same level. If you’re struggling to decide which option to put to the left or the right, go with the order you naturally tell the story. Because, when you speak you must choose which option to say first.

When telling a big story that involves several users, you’ll likely hit a point where two users are doing things at the same time. Many people get tempted to break the map into two maps at this point – one above the other so you can see it’s happening at the same time. I’m not a fan of that. Again, I want to use the vertical axis for decomposition and prioritization. If this happens in your story, put each user’s flow on the same level. And, when you’re asked “why did you put that user first” you can say “I “we put them first because when we tell the story we usually tell it by starting with them.” Remember, all stories, books, comic books, and movies move forward with one storyline – even when the storyteller has to inform the reader that this happened at the same time something else was happening.

Story maps aren’t precise communication tools like flow charts or other business process diagrams. You’ll need to use the map and lots of storytelling to communicate all the various ways individuals may use your product. No one understood those flow charts anyway.

4. Mapping the whole product when you’re trying add single features

I often hear from people that “I hate story maps because I need to map the whole product when I’m just trying to add a single feature.” No, you don’t. Just map that feature. Just map the story of the new feature. Start the story when users first touch it. End the story with them successfully using it and getting value. You’ll end up with a right sized map that tells the story of that feature.

Now, that said, many people like to use a high-level backbone of their whole product when discussing a new feature. It’ll help them see the impact of the new feature on different parts of the product. For example, it’s common for a feature to hit the configuration area of a product, to affect dashboards, or reports run in the product. Looking across the whole product backbone it’s easy to ask “where might this change other areas of our product?”

5. Not anchoring releases to an outcome

The real super-power of a story map comes when you’ve broken a user’s story down into lots of options and alternatives and then use the vertical axis to slice the map into a series of releases. It’s here where I often see people argue about what features belong in a first release or a second release, and then try to fill each release to capacity. Avoid that.

Instead decide what users you’ll be focusing on in each release, and in a sentence or two describe how they’ll be able to do things better in the future. What will they be faster at? Better at? Identify a few metrics that let you measure if they really are better or faster at those things. These are your outcomes. Once you’ve got those, then ask “what do they need to do to get those outcomes?” Ruthlessly remove anything they won’t need to get those outcomes.

For each thing they do need, try to split it. Ask “what’s the minimum we’d need to do for them to be successful? What could we defer to a later release?” We call this splitting and thinning.

When you anchor each release on a target outcome, you’ll find each release is smaller and more successful than you ever thought possible.

That’s it

You could and should watch the conversation I had with Shipra at Miro to summarize this stuff. And, we talk about a few other things too.

I’d love to hear from you about your common mistakes or missteps with story mapping. Or, about anything really. Please get in touch.

And, finally, if you haven’t taken a class with me, you should.