This question recently came from Douglas Ferguson (but I get asked a lot)
[In User Story Mapping], how do you typically handling multi-user processes that create branches?
Do you create different maps for different users and different flows?
My response:
I get asked this often, and do my best to avoid answering the question because I want to see what people come up with.
The only rules for me about mapping are that:
- I can tell a story – and I usually tell it left to right
- I can break the story down into options and details – and I usually do that top to bottom
That’s it. No more rules. And you can even break those if you have a good reason.
If we were writing a book here, the characters have options, but it’s a book, so they only do one thing. But, if we’re telling a story about an interactive product, people use the product differently at different times, they may do things in different orders, and they may make a decision that changes all the “steps” they’d do after that decisions. They won’t behave like characters in a book. That makes it messy. And, because people can do things in a variety of different ways, it makes any modeling process painful. So I avoid a lot of that pain by reminding myself that:
A story map is not a precise model of user’s workflow. It’s a tool that helps us work together to tell users’ stories.
Flatten the flow
So when someone says to me: “In this process the user does steps A and B, but in step C they make a decision. Then they might branch to steps D, E, and F, or they might take the other branch and do steps G, H, and I. How do I map that?”
In a flowchart it would look like this:
I usually tell them I’d put all those options in a left to right flow: A, B, C, D, E, F, G, H, and then I. It would look like this as a map:
Basically I put the options in the order someone tells the story. I use the telling of the story to add in the extra language like “users would make a decision in step C and they’d they continue at D, or jump over here to G. I don’t show the branches in a map the way I would in a flow chart. I use conversation to communicate the branches.
Roll it up
As I see that very long story mapped out the way I just drew it, it looks long to me. I might roll it up into 3 basic columns: the first stuff I do that leads to making a decision, the stuff I do in the first branch, and the stuff I’d do in the second branch. That map might look like this:
If you’re trying to hand off a story map without conversation to explain what’s going on inside it, then none of this works. And that’s when I remind you that Agile stories get their name from the action of story telling, not act of story documenting. If you really can’t use conversation to explain things, then you’ll need a workflow diagram, flow chart, use case, or some other model to do it.
If you think you might forget details about the branching, then It’s a good idea to annotate the stories or around the stories in the map. Write just enough to help you remember how to tell the story.
Flatten the flow across users
In a back and forth with Doug, he got back to me with this:
“Image this flow
merchant enters new product to catalog – user navigates catalog – user opens product detail – user presses order – production receives order – shipping ships product – user receives tracking info
Here the flow has multiple actors. My flows are a bit more complex and specific to my use case and can create branching, but from your FAQ it seems that I could just flatten it all out without much worry.”
Yup, you’ve got it. And you can see the map is embedded in the way you told the story.
Map the product flow across types of users
If you do that given the example above, you might end up with something like this:
I haven’t written in the details on the cards, but you get the idea I think. It’s now a map that tells lots of user’s stories inside the whole product.
Don’t map everything if you don’t have to
I’ve got to tell you I don’t build whole product maps like this unless I’m rebuilding a whole product. I usually work with companies that have a product on the market, and they’d like to introduce new features or capabilities into that product. One mistake they sometimes make is thinking they need to map the whole thing.
Don’t do that. It takes a lot of time. And the only reason to do it is to help others understand your whole product if they don’t already.
Instead, just map the change.
For example if I want to add a capability that lets a merchant add a special sale price to their product, I’d map the merchant’s part of the experience where they put the product on sale, and the shopper’s part of the experience where they see the product is on sale.
That small map might look like this:
Do what makes sense to you
I strongly suspect that if I’d given you no advice at all, you’d have figured this out on your own. So, if this saves you a little time, that’s cool.
And, even better, if you figure out something different that helped you in your situation, please share it back!