The Greenbox team has done good work. They Event Stormed and got the whole domain out of Maya’s head. The hotspots on the wall made it clear: subscriptions are the critical path – nothing else works without them.
Now they need to build something. And 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.
They need a way to turn that vague story into something concrete before anyone opens an IDE.
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 there are too many unknowns and it needs more research first. All three are useful outcomes. The worst thing you can do with a vague story is ship it unexplored, with unknown assumptions and no validation. You may choose to build part of it to learn what’s missing, then revisit and possibly rewrite the story before you commit to the delivery.
The technique uses four colours of index card (or sticky note, or virtual equivalent) to keep the conversation structured.
Four colours of card
Yellow is the story. One card. The thing you’re discussing.
Blue is for rules. These are the business rules, constraints, and acceptance criteria that govern how the story works. Each rule gets its own card.
Green is for examples. Concrete, specific instances that illustrate a rule. “If X happens, then Y.” These are the things that tell you what “done” looks like.
Red is for questions. Anything you can’t answer in the room. Unknowns, disagreements, things that need research or a decision from someone who isn’t here.
That’s it. Four colours, four purposes.
How to run one
The format is deliberately tight:
- Keep it short. Twenty-five minutes. Long enough to explore a story properly, short enough to stay focused. Set a timer. If you haven’t finished, the story is too big or too unclear. That’s useful information.
- Small group. Someone who understands the business, someone who’ll build it, someone who’ll challenge the assumptions. Three to five people is ideal.
- One story at a time. Don’t try to batch these. One story, one session.
- Write as you go. Someone states a rule, write it on a blue card. Someone gives an example, write it on a green card under that rule. Someone asks a question nobody can answer, write it on a red card.
The conversation flows naturally. Someone proposes a rule. Someone else challenges it with an example. Edge cases surface. Assumptions get exposed. The map grows organically.
The first session: “Subscribe to a produce box”
The Greenbox team gathers round a table. Maya, Tom, Priya, Jas, and Sam. Lee facilitates. Twenty-five minutes on the clock.
Lee places a yellow card in the middle of the table and writes on it: Subscribe to a produce box.
“Don’t try to define it,” Lee says. “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. Sarah 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 2nd April.”
Lee writes it on a green card: Sarah chooses small box ($25/week), pays with Visa 4242 → subscription confirmed, first delivery Thursday 2 April. “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 Sarah enters an expired card.”
Green card: Sarah 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 Sarah subscribes on Monday 30th March, she gets a box Thursday 2nd April. If she subscribes on Friday 3rd April, she gets a box Thursday 9th April.”
Two more green cards:
- Sarah subscribes Monday 30 March → first delivery Thursday 2 April
- Sarah subscribes Friday 3 April → first delivery Thursday 9 April
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. “Sarah subscribes Monday 30 March, first delivery Thursday 2 April. 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. Sarah subscribes Monday 30 March. → First delivery Thursday 2 April.
“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: Sarah 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: Sarah 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: Sarah 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.
If they’d had eight red cards and three green cards, that would be a clear signal: go away, answer the questions, and come back for another session.
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 disguised as 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 hitting 200 subscribers before the seed money runs out, 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.