The GreenBox team has been busy. Event Storming gave them shared understanding of the domain. Example Mapping made their stories concrete. Impact Mapping connected their work to business goals.
The result? Eighty-three stories in the backlog.
Eighty-three. And climbing. The team feels the weight of it. Every discovery session has surfaced more work, more edge cases, more things that need building. The techniques are working – the team understands the domain better than ever – but the sheer volume of what they’ve uncovered is starting to feel paralyzing. Priya scrolls through the list on her screen and her face goes still. Tom exhales audibly.
Lee looks at the list and raises an eyebrow. “Eighty-three is a lot. How many of these are actually ready to build?”
Tom scrolls through. “Maybe… twenty? The rest are ideas, or things that came out of Example Mapping red cards, or stuff Maya mentioned once in a standup.”
“Right,” Lee says. “Part of what we’re going to do today isn’t just organise these. It’s be honest about which ones you actually need. A story map isn’t just a way to arrange work – it’s a way to see what you can cut.”
Tom scrolls through the list in their project tracker. “Impact Mapping told us what matters,” he says. “But I’m looking at the referral programme and it’s five stories. The shortfall tool is three. I don’t know which of those stories need to ship together to actually work. If I build referral link generation but not referral tracking, have I shipped anything useful? What’s the minimum set of stories that adds up to something a customer can actually use?”
He’s not wrong. A flat backlog tells you what to build, and Impact Mapping told them what matters most. But neither tells you how those stories relate to each other, where the gaps are, or what subset of work adds up to a coherent experience for the user.
This is the problem User Story Mapping solves.
What User Story Mapping is
User Story Mapping is Jeff Patton’s technique for visualising the user journey and organising stories within it. The core idea: instead of a flat prioritised list, you arrange stories in a two-dimensional map that shows what users do and how your stories support those activities.
The structure has three layers:
- Activities run left to right across the top. These are the big things a user does, in roughly chronological order. This row is called the “backbone” – it holds the map together.
- Tasks sit below each activity. These are the specific things a user does within that activity.
- Stories sit below each task, prioritised top to bottom. Must-haves at the top, nice-to-haves at the bottom.
Left to right tells you the user’s journey. Top to bottom tells you priority. That’s the whole concept.
How it differs from Event Storming
If you’ve been following this series, you might wonder how this relates to Event Storming. They look superficially similar – sticky notes on a wall, arranged left to right – but they’re modelling different things.
Event Storming maps domain events: what happens in the system. “Payment Submitted.” “Box Packed.” “Subscription Created.” It’s about understanding the domain mechanics.
User Story Mapping maps user activities: what the user does. “Browse boxes.” “Subscribe.” “Manage subscription.” It’s about understanding the user journey and organising your work around it.
They complement each other perfectly. Event Storming tells you how the system works. User Story Mapping tells you how users experience it and what you should build when.
Building the GreenBox story map
Jas suggests running the session. She grabs a fresh wall, a stack of sticky notes, and the whole team. Lee watches her take charge of the room – finding the markers, arranging the space, framing the question – and says nothing until afterwards. Then he tells Maya: “She’s good. She thinks about the whole journey, not just the screen.” Maya nods. She’d noticed it too.
“Let’s start with the backbone,” Jas says. “What are the big activities a customer goes through with GreenBox, from first hearing about us to becoming a loyal subscriber?”
The team talks it through. Maya draws on her understanding of the customer journey. Sam brings the marketing perspective. After fifteen minutes, they have six activities across the top of the wall:
That’s the backbone. Left to right, it tells the story of a GreenBox customer’s journey. Not the system’s internals – the person’s experience.
Adding tasks
Next, the team fills in the tasks under each activity. These are the concrete things a user does within each activity.
Discover GreenBox:
- See a social media post
- Read a review or recommendation
- Visit the landing page
Browse Boxes:
- View available box sizes
- See what’s in season this week
- Check if their area gets deliveries
Subscribe:
- Choose a box size
- Enter delivery details
- Pay
- See their first delivery date
Receive First Box:
- Get a delivery notification
- Receive the box
- Check the contents against expectations
Manage Subscription:
- Pause for a week
- Change box size
- Update payment details
- Cancel
Refer a Friend:
- Share a referral link
- Friend signs up using the link
- Both get a reward
Some of these tasks prompt immediate discussion. Sam points out that “check if their area gets deliveries” is currently invisible – there’s nothing on the landing page that tells people where GreenBox delivers. Tom notes that “see their first delivery date” requires knowing the delivery schedule, which nobody has defined yet.
The story map is already surfacing gaps that were hidden in the flat backlog.
Adding stories
Now comes the meaty part. The team takes their existing eighty-three stories and places them under the relevant tasks. Some stories map neatly. Others don’t fit anywhere – which is revealing in itself.
Sam sticks a note under “Discover GreenBox” and pauses. “Hang on. I’ve got three marketing stories here – social media content, SEO landing pages, local press outreach. But none of them connect to anything Tom or Priya are building. If I run a press campaign and someone signs up, is the onboarding experience actually ready for them?”
Everyone looks at the map. There’s a gap. The “Discover” column has marketing work, but the “Browse” and “Subscribe” columns are still sparse. Sam’s press campaign could drive traffic to a half-finished experience.
“That’s exactly why we’re doing this,” Lee says. “A flat backlog would never have shown you that gap.”
Sam points at the gap between “Subscribe” and “Receive First Box” on the wall. “After signup, the customer’s next touchpoint is the box arriving. If anything goes wrong between those two events – payment fails, delivery delayed, substitution they hate – the only way they can tell us is email. We have no status page, no tracking, no FAQ.” She pulls up her spreadsheet of common support questions. “Sixty percent of my inbox is people asking things they should be able to find themselves.” The story map has surfaced the support tooling gap as a user experience problem, not an internal operations problem.
Then they add new stories where the map shows obvious gaps. Under “Check delivery area,” there were no stories at all. Under “Manage Subscription,” there were fourteen stories – far more than any other activity. One card, almost hidden in the supply-side column, reads “farm reliability scoring.” It goes up on the wall without much discussion – one of eighty-three things to eventually get to.
They prioritise vertically: must-haves at the top, nice-to-haves at the bottom.
Now the team can see the whole system at once. Not as a list of features, but as a journey with depth.
What the map reveals
Three things jump out immediately.
Gaps. The “Discover” column is thin. The team has been so focused on what happens after someone finds GreenBox that they’ve barely thought about how people find it in the first place. Sam flags this as a risk: “We can build the best subscription experience in the world, but if nobody knows we exist, it doesn’t matter.”
Over-investment. The “Manage Subscription” column is thick. Fourteen stories about pausing, changing, upgrading, downgrading, cancelling. Is that where the team should be spending its energy before they have subscribers? Probably not.
Missing connections. There’s nothing between “Receive First Box” and “Manage Subscription.” What happens after someone gets their first box? How do they become a regular? The map reveals a gap in the team’s thinking about retention.
None of this was visible in the flat backlog. The stories were all there, but without spatial arrangement, the patterns were invisible.
Release slicing
This is where User Story Mapping really earns its keep. Instead of arguing about which stories to do first – a conversation that usually degenerates into politics and personal preference – the team draws horizontal lines across the map.
Each line defines a release. Everything above the line ships in that release. Everything below waits.
The rule is simple: each release must tell a complete story. You can’t ship “Subscribe” without “Receive.” You can’t have payment without a landing page. Each horizontal slice must be a usable, valuable product – even if it’s a thin one.
Release 1 (MVP): A customer can find GreenBox, see what’s on offer, subscribe, pay, and receive their first box with a notification. That’s it. No pause button, no referrals, no delivery tracking. The bare minimum to prove the concept works and someone will pay for it.
Release 2 (Operational): Now that people are subscribing, add the operational essentials. Delivery tracking so customers aren’t left wondering. Pause and resize so they don’t cancel when they go on holiday. A delivery area checker so Sam stops fielding emails from people in postcodes they don’t cover. Basic feedback so the team knows if the boxes are any good.
Release 3 (Growth): With a working, operationally sound product, invest in growth. Referral programme. Gift subscriptions. The seasonal calendar that Jas has been wanting to build. Instagram integration for Sam’s marketing. The farm story content that Maya thinks will differentiate GreenBox from competitors.
Notice what happened. The team didn’t argue about whether referrals or delivery tracking should come first. The map made the answer obvious. Referrals are meaningless without a product worth referring. Delivery tracking matters the moment someone is waiting for a box. The spatial arrangement resolves priority debates that would have burned hours in a flat backlog.
A map is not a list
This is the key insight, and the one Jeff Patton hammers on repeatedly in his book: a backlog is a list, a story map is a plan.
You can have the same stories in both. The content is identical. But the arrangement changes everything.
A flat backlog says: “Here are 83 things to build, roughly in order.” It gives you sequence but not structure. You can’t see relationships. You can’t see gaps. You can’t tell if your next ten stories add up to something a user can actually use, or if they’re ten disconnected increments across six different activities.
A story map says: “Here is the user’s journey, here is the work that supports each part of it, and here is what we’re shipping when.” It gives you context. It makes conversations about scope concrete rather than abstract.
When Maya asks “What’s in Release 1?”, the team points at the wall. It’s right there. No spreadsheet filtering, no Jira query, no debate. The wall is the plan.
When to use User Story Mapping
Reach for this technique when:
- You’re planning releases. You have a pile of stories and need to figure out what subset makes a coherent, shippable product. The map makes slicing natural instead of arbitrary.
- You’re onboarding new team members. A story map is the fastest way to show someone what the product does, who uses it, and what the team is working on. It takes five minutes to walk the wall instead of thirty minutes of context-dumping.
- You’ve lost the plot. “We have 80 stories and no idea what to ship first” is the classic symptom. The map brings order without imposing a rigid process.
- Product and engineering are misaligned. When the product person is thinking in user journeys and the engineers are thinking in components, the story map bridges the gap. Both perspectives are visible on the same wall.
When NOT to use it
User Story Mapping is not the right tool for everything. Don’t use it when:
- You need to refine individual stories. That’s what Example Mapping is for. A story map tells you which stories to build and when. Example Mapping tells you what a story actually means.
- You need to understand the domain. That’s what Event Storming is for. A story map organises work around user activities. Event Storming uncovers the domain events and business rules underneath.
- You have a small, well-understood scope. If you’re building one feature with three stories, you don’t need a map. You need a conversation and a whiteboard.
The techniques in this series aren’t competitors. They’re a toolkit. Event Storming for understanding, Example Mapping for precision, Impact Mapping for alignment, and User Story Mapping for the big picture. Use the right one at the right time.
What the team learned
After two hours on the wall, the GreenBox team has something they’ve never had: a shared picture of the whole product they’re building, when they need to build each part, and why. Not just the next sprint, not just a prioritised backlog – a plan that connects what the team ships to what the customer experiences to what the business needs.
Tom can see where his subscription work fits in the larger journey, and why “pause” needs to ship complete – with resume – before they touch referrals. Priya can see which farm-side features are needed for Release 1 and which can wait without hurting the customer experience. Jas can see the user experience as a continuous flow rather than a collection of disconnected screens. Sam can see where marketing and operations intersect with what the team is building, and when he needs to have the courier contract ready. Maya can see the business she’s been carrying in her head, laid out on a wall for everyone to share – and she can see the path from 197 subscribers back to growth.
“I wish we’d done this four weeks ago,” Tom says.
Jas smiles. “We didn’t know enough four weeks ago. We needed Event Storming to understand the domain, and Example Mapping to make the stories real. This built on top of all that.”
She’s right. The story map works because the team already has shared understanding of the domain, clear examples for their stories, and agreement on what matters. User Story Mapping didn’t replace the earlier techniques – it gave them a place to organise everything they’d learned.
Looking at the wall, the team feels like they’ve cracked it. Four workshops, each building on the last, and they finally have a clear path from where they are to where they need to be.
But here’s the thing about workshops: they don’t always go this well. The GreenBox team had Lee facilitating, a founder who was willing to be challenged, and a team small enough that everyone could be in the room. Not every team has those advantages. And even this team had moments where things nearly went sideways – Tom’s scepticism about “spending three hours not coding” before the Event Storm, Maya getting defensive about her matching process during the Example Mapping session, the conversation that almost derailed into a debate about payment providers.
What do you do when a workshop goes wrong? When nobody argues, when the map reveals a political problem, when the red cards pile up and the story clearly isn’t ready but the sprint starts tomorrow? That’s next (coming 19 May).