The afternoon of the Event Storm, while the wall was still up, Lee took the hotspot Maya had picked off it (substitution policy: who decides, and how?) and ran the team through it with four colours of index card. Twenty-five minutes later the table held three green cards and eight red ones. Eight questions nobody in the room could answer: what counts as an equivalent vegetable, whether a swap can change the box price, how late in the week a substitution can happen, what Greenbox tells the subscriber, whether Mrs Patterson’s no-beetroot note outranks a shortfall. Lee squared up the red cards and handed them to Maya. “This story isn’t ready to build. Now you know exactly what to find out, and you didn’t pay for the lesson with a sprint.”
That’s the technique doing its job, and it deserves a proper introduction, because the team is about to lean on it more than anything else they’ve learned.
The hotspots also made the priority clear: subscriptions are the critical path, nothing else works without them. The first story on the board is: “Subscribe to a produce box.”
Sounds clear enough, right? That’s what they thought four weeks ago too, and it didn’t go well.
The story is too vague to build from. What does “subscribe” actually mean? What has to happen? What could go wrong? What does the customer see? Tom could start coding right now, but he’d be guessing, again, and the team knows where that leads.
What is Example Mapping?
Example Mapping is a structured conversation technique created by Matt Wynne. The idea is simple: get a small group together for a short, focused session, take a single user story, and break it apart until everyone agrees on what “done” looks like. What are the rules? What are the concrete examples? What can’t we answer yet?
By the end of the session, you know one of three things: the story is well understood and ready to build, the story is too big and needs splitting, or (like substitution) there are too many unknowns and it needs research first. All three are useful outcomes. The expensive fourth option is the default everywhere: shipping the story unexplored and discovering the assumptions in production.
The first session: “Subscribe to a produce box”
The next morning, the Greenbox team gathers round a table. Maya, Tom, Priya, Jas, and Sam. Five people plus Lee: about the right size. Much bigger and the conversation fragments; much smaller and the assumptions go unchallenged.
Lee sets a timer for twenty-five minutes. “If the timer beats us, that’s information too. It means the story is too big or too unclear to build.”
He deals four small stacks of index cards onto the table and walks through them as he goes. Yellow is the story, the thing being discussed: one card per session, and he writes Subscribe to a produce box on it and places it in the middle. Blue is for rules: the business rules, constraints, and acceptance criteria that govern how the story works, one per card. Green is for examples: concrete, specific instances that illustrate a rule. “If X happens, then Y.” Red is for questions: anything the room can’t answer. Unknowns, disagreements, things that need research or a decision from someone who isn’t here.
“Four colours, four purposes,” Lee says. “Write as we talk. Someone states a rule, it goes on blue. Someone gives an example, green, under the rule it belongs to. Something we can’t answer, red, and we keep moving. One story at a time; the next story gets its own session. And don’t try to define the story. Start with a concrete scenario. A real person doing a real thing. Tell me about a real person subscribing to a produce box.”
Starting with examples
Jas goes first: “Someone visits the site, picks a box, enters their card details, and they’re subscribed.”
Lee pushes back gently. “Who? Which box? What price? What happens so they know they’re subscribed? The more concrete the example, the more useful it is. Abstract examples hide assumptions.”
Jas tries again: “OK. Claire visits the site, picks a small box at $25 a week, enters her Visa ending in 4242, and gets a confirmation with a delivery date of Thursday the 19th.”
Lee writes it on a green card: Claire chooses small box ($25/week), pays with Visa 4242 → subscription confirmed, first delivery Thursday 19 October. “See the difference? The first version could mean almost anything. Everyone in the room would picture something slightly different. This one leaves much less room for ambiguity, and ambiguity is where assumptions hide, and assumptions are where the bugs, the waste, and the rework come from.”
“Give me another one. What else could happen?”
Tom: “The card gets declined. Say Claire enters an expired card.”
Green card: Claire tries to subscribe with expired Visa → no subscription, asked to retry with a different card.
“What happens then?” Lee asks. “Does she lose her box choice? Start over from scratch?”
Maya: “No, she just re-enters payment details. The box choice stays.”
Lee writes that detail on the green card. “Good, that’s exactly the kind of detail that would have been a surprise in code review if nobody asked.”
Maya: “We deliver on Thursdays. If someone subscribes on Monday, they should get a box this Thursday. If they subscribe on Friday, it’s next Thursday.”
Jas: “Should we ask about dietary preferences when they subscribe? Allergies, things they don’t want?”
Maya nods. “Mrs Patterson hates beetroot. We should probably –”
Lee reaches for a red card. “That’s worth solving, but is it part of subscribing, or is it its own thing?” He writes: Dietary preferences and allergies during subscription? and moves it to the parked area. “We’ll come back to it. For now, let’s finish the shape of this one.”
Lee pushes for dates: “Which Monday? Which Friday?”
Maya: “If Claire subscribes on Monday 16th October, she gets a box Thursday 19th October. If she subscribes on Friday 20th October, she gets a box Thursday 26th October.”
Two more green cards:
- Claire subscribes Monday 16 October → first delivery Thursday 19 October
- Claire subscribes Friday 20 October → first delivery Thursday 26 October
Context, action, outcome
Lee looks at the cards on the table. “Every solid example has three parts: the context, what’s true before anything happens, the action, what someone does, and the outcome, what should be true afterwards.”
He picks up the delivery date card. “Claire subscribes Monday 16 October, first delivery Thursday 19 October. What’s the context?”
Tom: “Delivery day is Thursday.”
Maya: “And the minimum lead time is three days.”
Priya: “And there’s no public holiday that week.”
“Right. None of that is on the card.” He rewrites it:
Context: delivery day is Thursday, minimum lead time is 3 days, no public holiday this week. Claire subscribes Monday 16 October. → First delivery Thursday 19 October.
“Now it’s self-contained. Anyone can pick up this card and understand not just what happens but why. And Priya’s point about public holidays, that’s on the card now. If someone reads this example in two weeks, they won’t have to guess whether we considered holidays. We did. It’s right there.”
Priya starts rewriting some of the earlier cards without being asked. This is Priya at her best, she sees structure where others see conversation, and she can’t leave a sloppy card on the table. The payment one becomes: Context: Claire has selected a small box ($25/week). She enters an expired Visa. → No subscription created, asked to retry. Box choice is preserved.
Not every example needs three paragraphs of context. But the discipline of asking “what’s the context?” catches the assumptions that aren’t obvious, and those are the ones that cause problems in production.
“What about Wednesday?” Tom asks. “If someone subscribes at 11pm on Wednesday, do they make the cutoff? And whose 11pm, ours or the customer’s?”
Maya hesitates on the cutoff. “I think so… but the farms need to have confirmed supply by then.” The timezone question she can answer: “We’re Perth only. Everything is AWST.”
“For now,” Tom says.
“For now,” Maya agrees. “When we hit Melbourne we’ll need to revisit. They’re on a different timezone and they have daylight saving. Perth doesn’t.”
Lee writes a blue card: All times are AWST (Perth). Then a red card: Exact cutoff time for same-week delivery? He places the red card off to the side.
“Red cards are good. They’re unknowns we’ve caught before they became expensive surprises.”
Questions and assumptions
Sam asks: “Can someone have two subscriptions? Like a small box to their place and a large one to their mum’s house?”
The room goes quiet. Maya hadn’t considered it.
Lee writes a red card: Multiple subscriptions per customer? Then he asks, “Is that something we need for the first version?”
Maya: “No. Definitely not for version one.”
“Good. Park it.” He moves the red card to a separate area of the table. “Anything that isn’t part of this story goes over here. We’re not losing it, we’re recognising it belongs somewhere else.”
Jas: “What about cancellation? Can they cancel any time?”
Another red card: What’s the cancellation policy? Parked.
“What about 3D Secure?” Priya asks. “Some cards need that extra authentication step.”
Red card: How do we handle 3D Secure? This one stays with the story, it’s a technical detail that affects the subscription flow directly. Tom volunteers to research it.
Generalising to rules
“OK,” Lee says. “We’ve got a good set of examples and questions. Now let’s look at what they have in common. If you look across several examples, you’ll start to see patterns, things that are always true, constraints that apply every time. Those patterns are rules. A rule is a general statement that a set of examples all obey. ‘Payment must succeed before a subscription is created’, that’s a rule. Every example we’ve written either follows it or tests what happens when it breaks.”
The team looks at the green cards spread across the table.
Maya sees it first: “There’s a box size choice. Small or large. That’s it for now.”
Blue card: Customer must choose a box size. He arranges the size-related green cards underneath it.
“Does the rule spark new examples? What could go wrong with box size selection?”
Priya: “What if they don’t choose? What if they hit ‘subscribe’ without selecting a size?”
Green card: Claire clicks subscribe without choosing a size → error, asked to choose.
Tom: “And can they change their mind later? Switch from small to large?”
Maya: “Yes, but not mid-week. It takes effect from the next delivery.”
Green card: Claire switches from small ($25) to large ($45) on Monday → change takes effect Thursday.
Lee nods. “The rule generates new examples, and the examples constrain the rule. It’s not just ‘choose a size’, it’s ‘must choose before subscribing, and can change with notice.’”
Tom: “Payment has to work too. No valid payment, no subscription.”
Blue card: Payment must succeed before subscription is created.
“What else can go wrong with payment?”
Sam: “What about when the weekly charge fails three weeks in? Card expired, insufficient funds?”
Maya: “First failed charge, we retry after 24 hours. Second failure, we email them. Third, we pause the subscription.”
Three new green cards:
- Weekly charge fails once → retry after 24 hours
- Two failures → email customer to update payment
- Three failures → subscription paused automatically
Tom whistles. “That’s a lot more than ‘payment must succeed.’” Something he assumed would be straightforward, payment works or it doesn’t, just turned into a state machine with five transitions. Twenty-five minutes ago, he would have built it wrong.
Jas: “And they need to know when their first box arrives.”
Blue card: Customer sees their first delivery date after subscribing.
Sam: “Public holidays. What if Thursday is a public holiday?”
Maya: “We’d deliver Wednesday instead. Or Friday. Depends on the courier.”
Red card: How do public holidays affect delivery dates?
“Notice what happened,” Lee says. “We started with examples, and the rules emerged naturally. Then the rules generated more examples, and those examples tightened the rules. If you start with rules, you tend to stay abstract. If you start with examples, you stay grounded.”
The map so far
The timer hasn’t gone off yet, but the team feels like they’ve covered the core shape. Here’s what the table looks like:
Four rules, eleven examples, three questions still attached to the story, and three parked for other stories.
The “too many red cards” signal
If you have more red cards than green cards, the story isn’t ready to build.
Three red cards against eleven green cards is fine, and those are just the ones attached to this story, not the parked ones. The Greenbox team decides to resolve the cutoff and 3D Secure questions before starting work, and to treat multiple subscriptions, cancellation, and dietary preferences as separate stories.
The substitution map the afternoon before had exactly the opposite shape: eight red cards, three green. The signal was clear, and the team went away with a list of questions instead of building on guesses.
This is one of the best things about Example Mapping. It doesn’t just help you understand a story, it tells you when you don’t understand it. A readiness check that looks like a planning session.
Second session: “Pause a subscription”
The next story up is “Pause a subscription.” A customer is going on holiday and wants to skip a week or two.
This time the session goes more smoothly. The team knows the domain better. Maya is in the groove of stating rules explicitly instead of assuming everyone already knows them.
Three rules emerge quickly: customers can pause for one or more weeks, they’re not charged for paused weeks, and they must pause at least three days before the next delivery.
The edge cases are where it gets interesting. “What about Tuesday?” Priya asks. “If the delivery is Thursday and they pause on Tuesday, is that three days?”
Maya hesitates. “I don’t think so… Monday to Thursday is three days. Tuesday to Thursday is two.”
“So Tuesday is too late,” Tom says. “But what does ‘three days before’ actually mean? Before midnight on Monday? Or 72 hours before the delivery window starts?”
Maya: “Before the end of Monday. If you pause any time on Monday, you’re fine. Tuesday, you’re not.”
They update the rule to be precise: pause must be requested before midnight AWST on the day three days before delivery. For Thursday deliveries, that’s end of Monday. Sam asks: “Does the same cutoff apply to unpausing? If I unpause on Wednesday, do I get a box Thursday?”
Maya: “No, same rule. You’d need to unpause by end of Monday to get Thursday’s box. Otherwise it’s the following week.”
One question comes up that nobody can answer: can a subscription stay paused indefinitely, or does something happen if a customer never resumes?
Three rules, seven examples, one question. Much cleaner ratio than the first session. This story is nearly ready to build.
Notice how much faster it went. The team is developing a shared language. When Maya says “three days before delivery,” everyone knows what delivery day means, how the weekly cycle works, what the constraints are. That shared understanding from Event Storming is paying off already.
Why Example Mapping is the one you’ll use most
Event Storming is brilliant for understanding a whole domain. You might do it once at the start of a project, or when entering a new area.
Example Mapping is different. You do it before every story. Every single one.
It’s a short conversation. It surfaces assumptions. It catches edge cases. It builds shared understanding. And it tells you when a story isn’t ready.
The Greenbox team starts doing Example Maps before picking up each new story. Before Tom and Priya start building, they spend twenty-five minutes with Maya and Jas mapping it out. The red cards tell them what to resolve. The green cards tell them what to build. The blue cards tell them the rules to enforce.
Three weeks in, they’ve stopped finding surprises in code review. The arguments about scope have disappeared. When Priya finishes a story, it matches what Maya expected, because they agreed on concrete examples before anyone wrote a line of code.
If you only adopt one technique from this series, make it Example Mapping. Twenty-five minutes. Four colours of card. Every assumption surfaced before it becomes a bug.
Tom sits in his car after the session and texts Sarah: “I just spent 25 minutes doing something I thought was pointless and it saved me a week of work.” Sarah replies: “You sound surprised that something other than coding was useful.” He puts the phone down without responding. But he’s smiling.
Now what?
The team has cards on a table and a shared understanding of what “subscribe to a produce box” means, concrete, unambiguous, agreed upon by everyone in the room.
But cards on a table aren’t software. Tom picks up his bag. “Right. I’m going to build this.”
“Which part first?” Lee asks. “You’ve got red cards to resolve, Maya needs the subscription system live and 200 subscribers on it before the second-tranche deadline, and some of these stories reduce more risk than others. What order gives you the most confidence that you’ll ship something useful by then?”
Tom looks at the cards. He knows what to build. He doesn’t know what to build first, or how to make the building predictable. None of them do. Not yet.
That’s where the first sprints come in, turning sticky notes into delivery, one fortnight at a time.