Turns out user story mapping is harder than I thought

When I get handed the job of standing up a development team, this is usually the order I run things in.

Scrum workshop → Inception deck → User story mapping → Product backlog refinement → Sprint planning → then straight Scrum from there

And out of all of those, user story mapping is the one I have never felt comfortable with.

I have done it plenty of times over the years, and I never once walked away feeling like I had really gotten it right.

I have been a scrum master for a few years now, and honestly, up until now I have just been bluffing my way through this part.

So why did it keep not working?

Looking back, I think the problem was how I was pulling out the activities.

In the sessions where I could feel it going sideways, the activities tended to come out looking like this.

Create a [thing] Search [things] View a [thing] Edit a [thing] Delete a [thing]

And look, I get it! For Twitter (I refuse to call it X), you would get this.

Create a tweet Search tweets View a tweet Edit a tweet Delete a tweet

But activities like these start from the screen, which means they start from the product that already exists in your head.

The part that stings: when I facilitate these sessions, I am the one telling everybody "don't think about screens!" — and there I was, quietly leading them straight into it. Not great.

If you want to see what is actually wrong with those activities, the easiest way is to swap the subject out for something else.

Take those five and change tweet to DM. Create a DM, Search DMs, View a DM … every single one still works.

An activity that survives that swap is not really doing its job as an activity.

The reason they all survive is that the subject is data, not a person.

The life of a piece of data has no sequence and no motive behind it, so there is nothing to place it on — not the horizontal axis, which is the flow, and not the vertical one, which is priority.

So how do you get the person back into the subject position?

Going back to the Twitter example, the persona is basically all of us, the general public.

Except Twitter has people who write and people who read, and lumping them together as "the public" mixes two different flows into one line.

So the first move is to narrow the persona down to the people who write.

Then think about what actually happens. You tweet because something set you off — you saw something, you thought something.

Which makes the first activity Run into something worth saying.

After that it comes easily: Write down what you thought Send it out Get a reaction Join the conversation Come back for more, and so on.

And once you have that, the user stories basically fall out on their own. Under Write down what you thought, I can enter what I want to say. Under Send it out, I can broadcast what I wrote. Under Get a reaction, I can see how much it landed, as a number.

So this is what user story mapping was supposed to be. Took me until my late thirties to actually feel it click.

I ran one of these again recently, on a product in the elder care space. I cannot share the details, so here is the blurred version of what the backbone came out as.

Take the inquiry Decide whether to accept them Sign the contract Understand their condition Build the care plan Watch how it goes Review and revise

As you can see, it is just the shape of the work itself.

Create a care plan document belongs underneath Build the care plan. It was never supposed to be an activity in the first place.

So why did it take me this long?

I have read up on user story mapping many times over the years, and honestly, examples that take the right approach seem to be pretty rare.

I also suspect it is because this is something you do inside a company. You cannot publish the board itself, so this kind of thing just does not get shared much.

Hope this is useful to somebody.