Story Mapping

In this issue, we discuss a tool that is completely misunderstood by most development teams - and yet it's such an essential part of working iteratively and incrementally that I use it in almost every place I work.

I once visited a company that proudly showed their extensive story map. It was incredibly detailed, covered a dozen personas, and nearly a thousand cards. They had it spread across multiple meeting rooms. It was cool to see a team so excited about user-driven work.

Then they used it to start a multi-year development project that was delivered too late .

For me, story mapping is a negotiation tool. You can do it in a few hours, not weeks. And there are ways to avoid the common mistakes most people make that lead to elaborate, pointless maps that nobody refers to again.

Read on to learn about when I reach for this technique, how to maximize buy-in, and how to avoid common pitfalls.

Context

Work has been going on for a while on a project, but nobody is really sure when it will be done. It seems like there are many areas that are important, and it's hard to decide which ones need to be done before it can be shipped. Pressure is increasing and stakeholders are getting frustrated at not seeing returns.

Or, maybe the project was moving fast and visibly at first, but now it's slowing down and getting bogged down in details. When designers and engineers aren't completely clear about what's in and out, they waste time on features that are not needed, or they expand the scope of features without noticing. Sometimes this is obvious 'goldplating', but other times it's more subtle - they are working on all of the scenarios they can think of, and some aren't important for your first release.

This is the classic situation that agile methods were created for 25 years ago: 'Just' break the work down into increments, and deliver one increment after another. There are countless books written on this process, and yet, many PMs haven't learned this skill yet. Maybe they started being PMs in a later stage of development where they were making tradeoffs between a handful of features, or just building one big feature.

Here in Europe it's common to find PMs who go around gathering 'requirements' for months and then just start building stuff off of the list. It's surprising how often I run into a PM who doesn't know how to make an incremental plan. And somehow this can happen even if they've been a product maanger for 10 or 20 years.

Pattern

Use a User Story Map as a negotiation tool with the team to figure out what your product increments are.

This pattern was most famously written about by Jeff Patton, and if you haven't read his article or book, go do that first!

So if Jeff has written so well about it, why do I bother including this in the playbook? 2 reasons:

1. It's a core play that I use so often that I wanted to note down some of my own insights so I can do it more effectively.
2. Story mapping is deeply misunderstood.

If you ask a PM, "Have you done story mapping before?" they almost always say yes. They might be confusing this with Customer Journey mapping or a similar user-centered design process. A Customer Journey map shows all the stages of the customer journey. Often it is as complete and detailed as possible. That's not a Story Map.

While User Story Maps are user-centered, they function quite differently, because they are designed to be re-arranged. The goal of user story mapping is to decide which user tasks and activities you want to improve first; which ones you will work on next, and which ones you will save for later.

A map looks like the picture at the top: a grid of cards, with user activities at the top, broken down into user tasks. The tasks will ultimately be arranged into product increments.

A map is a collaborative card-based activity, so you will probably do it in Miro, Figjam, or similar. (Miro comes with a User Story Mapping component that I use all the time. Because it uses Miro cards rather than stickies it gets annoying if you have more than 12-15 columns - which is a helpful limit anyway.)

How to find product increments with a Story Map

You can do the whole activity in 2-3 hours if you stay focused, but you might prefer spreading this over a couple of afternoons.

1. Gather your team. You could start out with just one other person for the first few steps, but try to expand to 3-5 people relatively quickly.
2. List your personas. You might already have a couple of user personas identified. Just identify the 2-3 that are most relevant. When we were recently doing this for a refund process, we identified the consumer, the merchant customer service rep, and the bank's disputes rep as our 3 personas.
3. List their main activities. These make up the backbone of your map. Try to tell the story of what your personas do together to achieve the value of your system, in 5-12 steps.
4. Break the activities into tasks. (This is a great moment to bring in a few more team members if you started with just one other person). Working in parallel, add tasks in columns underneath the activities, in the order of the natural flow (first, most frequent tasks first)
   1. You might want to consider adding one more level if things are getting complicated
   2. At this point engineers will often want to break down the work into components - frontend, backend, API, etc. Encourage them to do functional slices instead. Why? The whole point of this activity is to negotiate scope. You're trying to identify which elements of the scope are negotiable. The one exception is if your team is providing APIs that need to be consumed by a different company.
5. Draw a line. Make a blank area between the headings (activities) and the tasks below. Miro makes this easy by allowing you to add a 'release'. Use tape or draw lines to separate this space out. Pick an arbitrary date that's 20-40 days away - I recommend starting with the end of the month unless you have a more meaningful date.
6. Decide on your first increment. Now ask the group: What do we need to work on first to maximize our learning, or show progress? Ask the engineers to drag in the things they think they can do. (For more on how to facilitate this, check out the 'Convergence' chapter in my book, Remotely Productive).
7. Repeat for two more arbitrary timeboxes. If you don't have another idea, stick to 1-month timeboxes, even if you work in shorter sprints. A month is enough time for most teams to deliver something meaningful.
8. Book your demo. Agree on the day we will demo our first increment. Invite someone else to come join your demo
9. Start developing the first increment. End the meeting, copy some of the cards into Jira, and get to work.
10. Update the map a few days before the demo. You won't work in the story map every day, but if you come back 3-4 weeks later you'll be surprised how much more you know about everything–even other parts of the map that you didn't work on yet.

Cautions + Caveats

A couple of key points:

• Don't story map alone. If you work on your own and then try to give the team the map later, you'll end up with a model that satisfies you very much but nobody else really understands. If you start out working just with a designer or tech lead, bring in the rest of the team before you add more than 20 cards or so. That way the map belongs to everyone.
• Don't try to map a whole year at once. Story Mapping is not a comprehensive requirements analysis process. You don't need to get everything. You just want to get enough to allow you to identify the first couple of product increments. The details will come during the development process. (That's why it's called 'development'!)
• Limit to 100 cards. I prefer to start in the 50-60 card range because there's enough to talk about without making it hard for new people to orient and contribute. As you approach 100 cards, you start to forget what's on there already. This is a tool for visualizing and scope negotiation, not a complete spec.
• Let Jira diverge. It's ok if your day-to-day work system diverges from the map. At first, you might be tempted to copy in every user task as a story in Jira. But you'll discover more stories and tasks - that's ok. These are negotiation tools.