After four weeks of building the wrong thing, the GreenBox team knows they need a different approach. Lee’s advice was clear: get the domain out of Maya’s head and into shared understanding before anyone writes another line of code.
The technique Lee recommends is Event Storming. It was created by Alberto Brandolini, and the premise is disarmingly simple: get everyone in a room, cover a wall in sticky notes, and model the business process as a series of domain events.
No code. No architecture diagrams. No user stories yet. Just: what happens in this business, in what order, and where are the hard parts?
It sounds almost too simple to be useful. That’s what Tom thinks when Maya suggests it. “We’re going to spend three hours sticking notes on a wall?” But the simplicity is the point. The sticky notes are a constraint that forces everyone to express ideas in small, concrete units. You can’t hide behind vague hand-waving when you have to write a specific event on a specific note.
What you need
Event Storming doesn’t require fancy tools or expensive facilitators. You need:
- A long wall (or a very long roll of paper stuck to a wall)
- Sticky notes in four colours (orange, blue, yellow, pink – Lee will explain what each means)
- Markers (one per person – thick ones so you can read the notes from a distance)
- Everyone who matters in the room: developers, domain experts, product people, operations
- Two to four hours of uninterrupted time
Setting up
Maya books the meeting room with the biggest wall. She grabs sticky notes from Officeworks – four packs, one of each colour. She invites the whole team: Tom, Priya, Jas, Sam. She also invites two of her farming contacts, Dave and Rachel, who she hopes will eventually supply GreenBox. They know the supply side in ways the team doesn’t.
Dave Morrison arrives ten minutes early. He’s 58, laconic, and deeply sceptical of anything that happens in a meeting room. He’s been to “workshops” before – the last one was run by a government agricultural adviser and produced a glossy brochure that nobody ever opened. He’s here because Maya asked personally, and because she grew up on a farm, and because that counts for something. He shakes Lee’s hand and eyes the wall of blank paper with the expression of a man who has seen a lot of fences built in the wrong paddock.
Rachel, who runs a smaller mixed farm nearby, mentions her “dodgy broadband” when Lee hands her a marker. “Took me twenty minutes to load the map to get here,” she says. “Satellite internet. Works when it feels like it.” Sam makes a mental note – if GreenBox ever builds a farm portal, it’ll need to work on a connection that drops out halfway through a form submission. Nobody else thinks much of it at the time.
Seven people. One wall. Three hours blocked out on a Tuesday morning.
Lee offered to facilitate, which helps enormously. The facilitator’s job isn’t to have domain knowledge – it’s to keep things moving, ask awkward questions, and make sure the quiet people get heard. You can run a session without a dedicated facilitator, but it’s harder. Someone inevitably gets sucked into the content and stops managing the process. If you can borrow someone who’s done it before, do.
Phase one: chaos
Lee starts by explaining the format. He holds up the four colours of sticky note and runs through them quickly:
- Orange – things that happen, written in past tense. “Payment Submitted.” “Box Packed.” “Farm Confirmed Availability.” These are the backbone – the story of how the business works, told as a sequence of things that already happened. (Lee calls them “domain events,” but at this point nobody cares about the jargon. They’re just things that happen.)
- Blue – decisions or actions that make those things happen. “Submit Payment.” “Pack Box.” Someone or something chose to do this. If orange is “what happened,” blue is “what triggered it.”
- Yellow – who or what is involved. A customer clicking a button. A farmer calling with availability. A scheduled job that runs overnight. The people and systems in the story.
- Pink – problems, questions, disagreements. Anything that makes someone say “wait, how does that work?” or “I thought it worked differently.” “These are the gold dust,” Lee says. “When you spot something that doesn’t make sense, or that two people disagree about, slap a pink note on it. Don’t try to resolve it now. Just mark it. We’ll get to pink notes later in the session – for now I just want you to know they exist.”
“We’ll start with just orange,” Lee says. “Only events. Write each one in past tense on an orange note. Don’t worry about order. Don’t worry about getting it right. Just get everything out of your heads and onto the wall. Keep the pink notes in your pocket for now – we’ll come back to them.”
He gives one important instruction: no talking during this phase. Just write and stick. Conversation comes later.
He sets a timer for twenty minutes and says go.
What follows is beautifully chaotic. Everyone grabs orange sticky notes and starts writing. Maya is writing rapidly – “Farm Listed Produce,” “Box Packed,” “Subscription Created,” “Weekly Menu Decided.” Tom writes “Payment Processed,” “Account Created,” “Subscription Cancelled.” Priya writes “Inventory Updated” and “Farm Onboarded.” Jas writes “Customer Signed Up” and “Box Previewed.” Sam writes “Delivery Scheduled” and “Customer Complained” (Sam always thinks about the operational realities).
Dave, one of the farmers, writes “Harvest Confirmed,” “Surplus Reported,” and “Growing Schedule Committed.” Rachel hesitates over her next note, then writes “Crop Failed” quickly and sticks it on the wall without looking at it. She’s thinking about the 2019 frost that wiped out Dave’s entire tomato crop. Dave sees it go up and his jaw tightens, but he says nothing. Rachel also writes “Delivery Window Missed” and “Price Renegotiated.” These are events the team hadn’t considered at all. Nobody on the GreenBox team had thought about what happens on the farm before produce arrives at the packing facility.
Priya notices Rachel writing “Crop Failed” and reaches for a pink note – she has questions. Lee catches her eye and taps his watch. “Good instinct. Hold that thought for the pink notes phase. Right now, just orange.” Priya nods and puts the pink note back, but she doesn’t forget the question.
Within twenty minutes, there are about sixty orange sticky notes scattered across the wall in no particular order. Some are duplicates. Some contradict each other. “Payment Processed” and “Payment Confirmed” might be the same event, or they might not. “Customer Signed Up” and “Account Created” look like duplicates. That’s fine. That’s the point. The goal of this phase is volume, not precision.
Phase two: the timeline
Lee gets everyone to step back and look at the wall. “Now let’s put these in order. Left to right, earliest to latest. Talk to each other. If you disagree about where something goes, that’s interesting – stick a pink note on it and we’ll come back to it.”
This is where the real conversations start.
Maya picks up “Farm Listed Produce” and puts it early on the timeline. Tom picks up “Customer Signed Up” and puts it at the start. Priya asks, “Which comes first – do we need farms onboarded before customers can sign up, or can customers sign up before we have supply?”
Maya pauses. “Good question. We need to know we can fulfil before we take subscriptions. So farm onboarding is first.”
Tom didn’t know that. He’d been building the subscription system in isolation, assuming customers came first. One sticky note conversation, and an assumption is surfaced and resolved.
There’s a brief tangent about whether “Payment Submitted” and “Payment Confirmed” are the same event. Tom explains they’re not – one is the customer clicking “pay,” the other is Stripe confirming the charge went through. A payment can be submitted and then fail. Maya hadn’t thought about that. Priya makes a note that they’ll need to handle failed payments – another pink note for the wall.
The duplicates get merged. “Customer Signed Up” and “Account Created” collapse into a single event. “Growing Schedule Committed” gets moved to a parallel swim lane because it happens on a different timeline to the customer flow. The wall starts to take shape.
The team works through the timeline together. After thirty minutes of shuffling, arguing, and clarifying, a rough sequence emerges:
Fifteen events. That’s the core flow of GreenBox, from first contact to feedback. It took the group about an hour to get here, and already the room feels different. Everyone can see the same picture.
Notice the structure that’s emerged. Farm onboarding happens first – Maya was right about that. GreenBox needs supply before it can take subscribers. But after that, the supply side – farms listing weekly produce, supply being aggregated and matched to demand – repeats every week for as long as customers stay subscribed. The one-time events (farm onboarding, customer signup, payment setup) are the scaffolding. The recurring events (weekly supply matching, packing, delivery) are the business. Tom is already thinking about how this affects the data model.
Phase three: commands and actors
Lee hands out blue and yellow sticky notes. “For each event, let’s figure out what triggers it. Write the command on a blue note, and who or what performs the command on a yellow note.”
This phase goes faster because the timeline provides structure. But it surfaces new questions.
“Who decides substitutions?” Jas asks, placing a blue “Decide Substitution” note next to “Substitution Decided.”
“I do,” Maya says. “For now, anyway. Eventually maybe an algorithm, but right now it’s judgement. You need to know the produce – you can’t just swap beetroot for lettuce.”
Tom had assumed substitutions would be automatic. He was planning a simple algorithm: if item A is unavailable, pick the next cheapest item in the same category. Maya is telling him that’s not how it works at all. The substitution logic is a core part of the value proposition, and it requires domain expertise.
Pink sticky note goes on the wall: “Substitution policy – who decides, and how?”
Sam asks another question: “Who dispatches the boxes? Us, or a courier?”
Maya says, “We’ll use a local courier for now, but eventually I want our own drivers. The delivery experience matters.”
Sam writes a pink note: “Delivery logistics – own drivers vs courier, and when do we switch?”
The actor layer reveals something interesting about “Supply Aggregated.” Who does the aggregating? Right now it would be Maya, manually checking what each farm has submitted. But with ten farms, that’s manageable. With fifty, it’s a full-time job. The yellow note says “Maya” but really it should say “System” – eventually. Another pink note: “When does supply aggregation need to be automated?”
Priya points to the bracket the team added during the ordering phase – the one marking where the weekly cycle starts. “Every actor from here onwards is doing something every week,” she says. “But the yellow notes don’t show that. Maya doesn’t aggregate supply once. She does it every Wednesday.” The actor layer makes the repeating workload visible in a way the event timeline alone didn’t.
Phase four: hotspots
By now the wall is covered. Orange notes tracing what happens, in order. Blue notes beneath them showing what triggers each step. Yellow notes above showing who’s involved. And scattered across the whole thing, pink notes marking every question, disagreement, and “wait, how does that actually work?”
Lee gathers everyone around the hotspots. “These pink notes are the most valuable thing on the wall. Every one of them is a misunderstanding you’ve caught before it became a bug, a wrong assumption, or a wasted sprint.”
The team counts twelve pink notes. The four biggest clusters:
Supply shortfalls. What happens when total farm supply doesn’t cover subscriber demand for the week? Rachel explains that this is completely normal in farming – “You think you’ll have twenty crates of zucchini, then the slugs get in.” Dave adds that some farms will over-promise because they don’t want to lose the contract. “We’ve all done it,” he says. “If you say you can’t supply, you lose the contract. Someone else gets it. So you say yes and hope the crop comes through. Sometimes it doesn’t.”
The team needs a process for handling shortfalls, and it needs to be baked into the weekly cycle, not treated as an exception. This is a design decision that affects everything: the commitment deadline for farms, the buffer stock policy, the customer communication if a box has fewer items than expected.
Substitution policy. This one sparks the longest argument of the session. Tom thought boxes had fixed contents – the same items every week, based on what the customer selected at signup. Jas thought customers picked individual items each week, like a supermarket order. Maya says neither is right. The box contents change weekly based on what’s available, and the curation is GreenBox’s differentiator. The customer doesn’t choose. They trust GreenBox to choose well.
Three people, three completely different mental models. If the team had kept building without this conversation, they’d have shipped three different products.
Delivery logistics. Sam raises the practical questions nobody else had thought about. What’s the delivery window? What happens if nobody’s home? Who handles complaints about damaged produce? Can customers change their delivery day? Is there a minimum order density per area to make delivery economical? None of these have answers yet, and every one of them affects the software.
Seasonal availability gaps. Rachel explains something the team hadn’t considered at all. In Western Australia, summer is abundant, but late winter is lean – fewer varieties, smaller yields, and some crops just don’t grow. What does GreenBox do during those weeks? Pause subscriptions? Source from further afield and compromise on the local promise? Offer a reduced box at a lower price? This is a business model question disguised as a supply chain problem.
The remaining hotspots are smaller but still important: how do farms get paid, what happens when a customer wants to skip a week, how is feedback collected and acted on, what are the deadlines for each step in the weekly cycle. None of them are show-stoppers individually, but together they represent the operational complexity that nobody had mapped before today.
The arguments are the point
About ninety minutes into the session, Tom and Maya have a proper disagreement. Tom is placing the “Supply Matched to Demand” event and says, “So the system automatically allocates produce to boxes based on the subscription sizes?”
Maya shakes her head. “No. I look at what’s come in from the farms, I think about what makes a good combination, and I decide what goes in each box size. It’s not just weight and price matching. A box needs to make sense as a meal plan for the week.”
Tom looks frustrated. He’s been building things for twelve years. He can hear the problem being described, and his instinct is to solve it with code – that’s what he does, that’s who he is. Being told that the answer is “Maya decides” feels like being told the problem isn’t worth solving properly. “So there’s no algorithm? You just… decide?”
“For now, yes. The algorithm is my brain.” Tom says nothing, but the thought flickers: the substitution logic “could be automated eventually.” Maya catches his expression. “Eventually,” she says, with a weight that closes the topic for now.
Lee steps in. “This is great. Put a pink note on it. The question is: can this scale? And if not, what does the handover from Maya-decides to system-decides look like?”
This is exactly the kind of conversation that Event Storming is designed to provoke. The argument isn’t a problem – it’s the discovery working. Tom now understands that the matching process is far more nuanced than he assumed. Maya now understands that if they want to scale, they’ll eventually need to codify her decision-making process. Both of those insights are worth the entire session.
What does healthy disagreement actually sound like? It sounds like: “I thought the box contents were fixed each week, but you’re saying they change – can we explore that?” It sounds like Priya asking “which comes first, farm onboarding or customer signup?” and being genuinely uncertain about the answer. It sounds like two people pointing at the same sticky note and realising they mean different things by the same word. Unhealthy silence, by contrast, sounds like everyone nodding along while privately picturing something different. If the room is quiet and everyone seems to agree, the facilitator should worry. Silence in an Event Storming session usually means people are being polite, not that they actually agree.
There’s a quieter but equally important moment when Jas admits she’d been designing the customer experience around item selection. “I thought the whole point was letting customers choose,” she says. “Like a farmers’ market online.” Maya gently corrects her: the point is the opposite of choosing. Customers are busy. They don’t want to browse and pick. They want to open their door and find a box of good stuff.
Jas pauses. She’s been designing the wrong product for four weeks and nobody told her. She can feel the heat rising in her face. Then something clicks. “That actually changes everything about the landing page. The value proposition isn’t choice – it’s trust.”
Nobody told Jas she was wrong at any point during the first four weeks. She’d been designing in good faith based on an assumption that nobody thought to challenge. Event Storming created the space for that challenge to happen naturally, without blame.
What emerged
By the end of three hours, the wall tells a story that nobody in the room could have told alone. Maya knew the farming side but hadn’t thought through the software implications. Tom and Priya understood the technical constraints but had wrong assumptions about the domain. Jas had been designing for a product that doesn’t exist. Sam had operational questions that nobody else had considered.
| Before | After |
|---|---|
| Maya had complete domain knowledge – but it wasn’t shared | Shared timeline of 15 core domain events, visible on a wall |
| Tom’s subscription model was built on wrong assumptions | Key misunderstandings resolved (box contents, substitution logic, farm onboarding) |
| Priya’s farm portal had fundamental unanswered questions | 12 hotspots identified and prioritised |
| Jas had designed for a product that doesn’t exist | Clear picture of what to build first |
| Sam’s operational concerns hadn’t been heard | Everyone aligned on the same domain model |
The team now has:
- A shared timeline of the entire business process, visible on a wall
- Twelve concrete hotspots that need resolution before anyone writes code
- The knowledge that substitution logic, supply management, and seasonal planning are core domain problems – not edge cases to handle later
- A much clearer sense of what “version one” should and shouldn’t include
All of that from three hours and a pile of sticky notes.
The key insight
The session resolved in three hours what would have taken weeks to discover through code. Every one of those twelve hotspots was a potential sprint of wasted work. Some of them – like the fundamental disagreement about whether customers choose their box contents – would have caused a full rewrite if discovered in production.
The cost of discovery was seven people for three hours. About twenty person-hours. The cost of discovering the same things through code would have been weeks of building, reviewing, arguing, and rebuilding. The maths isn’t even close.
And it’s not just about avoiding waste. The team is now aligned. When Tom goes back to the subscription model, he knows it needs to support variable weekly contents. When Priya builds the farm portal, she knows about commitment deadlines and shortfall reporting. When Jas redesigns the customer experience, she’s designing for trust, not choice. When Sam plans operations, he has a list of logistics questions that need answers. Everyone is building toward the same product because they all stood in front of the same wall.
Facilitation matters
A few things Lee did that made the session work:
He enforced the no-talking rule in phase one. When people talk too early, the loudest voices dominate and the quieter participants defer. The silent writing phase gives everyone equal weight. Dave and Rachel, who might have felt like outsiders in a tech team’s meeting, produced some of the most important events because they were writing, not competing for airtime.
He kept asking “what happens next?” and “what could go wrong?” These two questions drive the entire session. “What happens next?” extends the timeline. “What could go wrong?” generates hotspots. The second question is the more valuable one, because it forces the group to think about the unhappy paths – and that’s where most of the domain complexity lives.
He didn’t let anyone open a laptop. The moment someone starts Googling or checking Slack, they’re mentally out of the room. Event Storming works because everyone is physically engaged with the wall, moving sticky notes, pointing, arguing. Screens kill that energy.
He time-boxed ruthlessly. Three hours is enough for a first pass. It’s tempting to keep going – the conversation is flowing, people are engaged, new insights keep coming. But after three hours people are tired and the returns diminish. Better to photograph the wall, take a break, and come back for a deeper session on the hotspots if needed. The wall isn’t going anywhere.
When to use Event Storming
Event Storming shines when:
- You’re entering an unfamiliar domain. If your team doesn’t deeply understand the business process, you need to surface that understanding before you build. GreenBox is a perfect example – the developers assumed farming logistics were simpler than they are. Most domains are more complex than they first appear, and the complexity hides in the parts you don’t think to ask about.
- You’re kicking off a new project. Even if individual team members understand parts of the domain, they probably don’t share a mental model. Event Storming builds that shared model explicitly.
- You have access to domain experts. The technique depends on having people in the room who know how things actually work. Dave and Rachel’s farming knowledge was essential to the GreenBox session.
- You keep finding surprises in code review. If every pull request surfaces a new domain question, you haven’t done enough discovery. Event Storming is a way to front-load that learning.
When not to use it
Don’t reach for Event Storming when:
- The feature is small and well-understood. Adding a password reset flow doesn’t need a three-hour workshop. Save the technique for when there’s genuine domain complexity.
- You don’t have the right people available. Running an Event Storming session without domain experts is just developers guessing together. That’s worse than useless – it creates false confidence.
- The team already shares a strong mental model. If everyone genuinely understands the domain and agrees on how it works, Event Storming will confirm what you know without adding much. Spend the time elsewhere.
- You’re under severe time pressure and the scope is clear. If you have two days to build a well-defined integration and everyone knows what it does, a workshop is overhead. Use your judgement. The danger is that “we all understand it” is often an untested assumption – but sometimes it’s genuinely true.
What happens next
The GreenBox team leaves the session energised but also a bit overwhelmed. Twelve hotspots is a lot. They can’t tackle everything at once, and right now everything feels equally important.
Maya photographs the entire wall – five panoramic shots stitched together. Sam volunteers to transcribe the events and hotspots into a shared document. Tom, who was sceptical about spending three hours not coding, admits he’s glad they did it. “I would have spent a week building automated substitution logic,” he says. “That would have been completely wrong.”
Lee and Dave walk to the car park together. Dave pulls his keys out of a jacket that’s seen a decade of Margaret River weather. “That wasn’t as bad as I expected,” he says.
Lee smiles. “High praise from a farmer.”
Dave pauses by his ute. “The thing about crop failures. That’s not a what-if for us. That’s a Tuesday in August.”
“I know,” Lee says. “That’s why you needed to be in the room.”
Lee comes back from the car park and finds the team standing in front of the wall, arms folded, looking slightly stunned. There’s a lot on that wall. Twelve hotspots, fifteen core events, dozens of questions. Tom’s face says “where do we even start?” Priya is reading the pink notes methodically. Sam is counting them.
“That’s a lot,” Maya says quietly.
“It is,” Lee says. “And you surfaced all of it in three hours. Every one of those pink notes is a misunderstanding you caught before it became code. That’s the trade you made today: three hours of sticky notes instead of three months of rework.”
He lets that sit, then: “You’ve mapped the territory. Now you need to turn that understanding into something you can build. Pick one of those stories – the most important one – and make it concrete. What are the rules? What are the examples? What are the edge cases?”
The technique for that is Example Mapping, and it’s the subject of Part 3 (coming 7 April).