The Greenbox team has been busy. Event Storming gave them shared understanding. 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. Every discovery session has surfaced more work, more edge cases, more things that need building. Priya scrolls through the list on her screen and her face goes still. Tom exhales audibly.
Lee looks at the list. “Eighty-three is a lot. How many are actually ready to build?”
Tom scrolls. “Maybe… twenty? The rest are ideas, or things that came out of red cards, or stuff Maya mentioned once in a standup.”
“Right. Part of what we’re going to do today isn’t just organise these. It’s be honest about which ones you actually need.”
Tom has a sharper question. “Impact Mapping told us what matters. But I’m looking at the referral programme and it’s five stories. The shortfall tool is three. I don’t know which stories need to ship together to actually work. If I build referral link generation but not referral tracking, have I shipped anything useful?”
He’s not wrong. A flat backlog tells you what to build. Impact Mapping told them what matters. But neither shows how stories relate to each other, where the gaps are, or what subset adds up to a coherent experience.
What User Story Mapping is
User Story Mapping is Jeff Patton’s technique for visualising the user journey and organising stories within it. Instead of a flat list, you arrange stories in a two-dimensional map.
Three layers:
- Activities run left to right across the top. The big things a user does, roughly chronological. This row is called the “backbone.”
- Tasks sit below each activity. 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 below.
Left to right tells you the user’s journey. Top to bottom tells you priority.
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 quietly: “She’s good. She thinks about the whole journey, not just the screen.”
“Let’s start with the backbone,” Jas says. “What are the big activities a customer goes through, from first hearing about us to becoming a loyal subscriber?”
After fifteen minutes, six activities:
That’s the backbone. Not the system’s internals – the person’s experience.
Adding tasks and stories
The team fills in the tasks under each activity, then takes their eighty-three stories and places them. Some map neatly. Others don’t fit anywhere – which is revealing in itself.
Sam sticks a note under “Discover Greenbox” and pauses. “I’ve got three marketing stories here – social media, SEO, 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 “Browse” and “Subscribe” are sparse.
“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.” “After signup, the customer’s next touchpoint is the box arriving. If anything goes wrong – 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. “Sixty percent of my inbox is people asking things they should be able to find themselves.”
They add new stories where the map shows gaps. Under “Check delivery area,” there were no stories at all. Under “Manage Subscription,” there were fourteen – far more than any other activity. One card, almost hidden in the supply-side column, reads “farm reliability scoring.” It goes up without much discussion.
Three things jump out:
Gaps. The “Discover” column is thin. Sam flags it: “We can build the best subscription experience in the world, but if nobody knows we exist, it doesn’t matter.”
Over-investment. Fourteen stories about pausing, changing, upgrading, downgrading, cancelling. Is that where the team should spend its energy before they have more subscribers?
Missing connections. Nothing between “Receive First Box” and “Manage Subscription.” What happens after someone gets their first box? How do they become a regular?
None of this was visible in the flat backlog.
Release slicing
This is where User Story Mapping earns its keep. Instead of arguing about which stories to do first, the team draws horizontal lines across the map. Each line defines a release. Everything above ships in that release. Everything below waits.
The rule: each release must tell a complete story. You can’t ship “Subscribe” without “Receive.” Each horizontal slice must be a usable product – even if it’s thin.
Release 1 (MVP): Find Greenbox, see what’s on offer, subscribe, pay, receive a box with a notification. The bare minimum to prove someone will pay.
Release 2 (Operational): Delivery tracking, pause and resize, delivery area checker, basic feedback. The essentials for keeping people subscribed.
Release 3 (Growth): Referral programme, gift subscriptions, seasonal calendar, Instagram integration. Growth features that only matter once the product works.
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.
When to use User Story Mapping
- You’re planning releases and need to figure out what subset makes a coherent, shippable product.
- You’ve lost the plot. “We have 80 stories and no idea what to ship first” is the classic symptom.
- Product and engineering are misaligned. The story map bridges user journeys and engineering components on the same wall.
When not to use it
- You need to refine individual stories. That’s Example Mapping.
- You need to understand the domain. That’s Event Storming.
- You have a small, well-understood scope. Three stories don’t need a map. They need a whiteboard.
What happens next
Looking at the wall, the team feels like they’ve cracked it. Four workshops, each building on the last, and they have a clear path from where they are to where they need to be. Event Storming gave them the domain. Example Mapping gave them concrete stories. Impact Mapping connected the work to goals. And now User Story Mapping shows them the whole journey, with release slices that make planning obvious instead of political.
“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.”
The team knows what to build. They know the order. They know what a coherent release looks like. For the first time, the whole product is visible on a single wall.
But sometimes workshops go wrong – the techniques are sound, but the humans are complicated. And a harder question is coming. The story map is beautiful. The release slices are clean. The team is confident they’re building the right thing.
They haven’t asked the customers yet.
Forty percent monthly churn will force that question in ways the team doesn’t expect. Because it turns out the answer to “what’s for dinner?” isn’t just a box of vegetables – it’s a job to be done.
The Greenbox story continues in Finding the Fit. I'll be writing about a few other things in the meantime -- the next chapter lands around 23 April.