The Workshop: Event Storming

This is the pattern. If you want the story of Event Storming in action, read Event Storming: Building Shared Understanding — the Greenbox team running their first session. This post is the reference you keep open the morning of.

Intent

Map a process as a sequence of things that happened, using sticky notes on a wall, so that the people who know different parts of it build one shared mental model.

Also Known As

Rarely called anything else. Sometimes confused with user journey mapping (Event Storming maps the system from the inside; journey mapping maps the customer experience from the outside) and with process modelling (Event Storming is discovery; process modelling usually documents an already-agreed flow). Invented and named by Alberto Brandolini in 2013.

Motivation

Two developers build the same feature two different ways because nobody said out loud that “box packed” means one thing to the warehouse and a different thing to customer support. An on-call engineer discovers at 3am that the billing cron is actually three scheduled jobs owned by three different teams. A product owner writes a story for a flow that, it turns out, doesn’t work the way anyone in the room thought it did.

These are not problems anyone can fix in isolation. They’re problems caused by isolation — by each person carrying their own model, each model slightly wrong in a different place, and nobody ever putting the models next to each other to see the gaps.

Event Storming exists to put the models next to each other. The wall is the shared surface. The sticky notes are the forcing function: you can’t hide behind vague hand-waving when you have to write a specific thing on a specific note and stick it where everyone can see.

Applicability

Use when:

• Your team doesn’t share a mental model of how a process actually works
• You’re entering an unfamiliar process and need to understand it
• You’re inventing a new process and need to agree on what should happen
• You’re reviewing an incident, a migration that went wrong, or a deployment pipeline that keeps surprising people
• You’re starting a new project or a major new feature area

Don’t use when:

• The scope is small and well-understood
• You can’t get the right people in the room
• The team genuinely already shares a strong, tested mental model

Levels. Alberto Brandolini distinguishes three, and the level you pick changes the whole shape of the session. Start at Process Level unless you have a specific reason not to.

Level	Scope	Duration	Output
Process Level (default)	One specific process, flow, or pipeline	2–3 hours	Precise shared model, hotspot list, vocabulary
Big Picture (zoom out)	A whole domain or large subsystem	Half a day to several days	Cross-team alignment, process-level hotspots surfaced
Software Design Level (zoom in)	Boundary and aggregate shape of the code	2–3 hours	Architectural sketch ready for modelling

Process Level is what most teams actually need. You have a specific pipeline, flow, or process that’s broken, unclear, or about to be built. You don’t need to map the entire business — you need to map the thing your next three sprints will touch. Zoom out to Big Picture only if you can’t agree on where the process starts and ends. Zoom in to Software Design Level only after Process Level has clarified the flow.

Participants

Facilitator. Does not participate in content — their job is to manage the process, ask questions, and keep things moving. Ideally someone who’s run one before. If that’s you, this post is your script.

Domain experts — the people who know how the process actually works. For an infrastructure session this is the SRE who carried the pager. For a deployment session it’s the engineer who’s rolled back the most builds. For a business-process session it’s the warehouse lead, the support agent, the farmer.

Developers — at least one, including a junior if you have one. Juniors ask the questions seniors have stopped asking. They catch mismatches between the model in the room and the model in the code because they haven’t yet internalised either.

Product and design — the people who shape what gets built. They turn the wall into stories, screens, and scope.

Operations / SRE — for deployment, incident, or toil-heavy sessions, these are the domain experts. Don’t tuck them in as afterthoughts.

Group size: 5–8. Fewer and you don’t get enough perspectives; more and the conversation collapses under its own weight. If you’re forced above 10, split into two sessions with overlapping attendance and reconcile afterwards.

Who to leave out:

• End users and customers — their presence changes what insiders will say, because people self-censor around the people they serve. Interview users separately and bring their words into the room.
• Senior leaders who can’t stop correcting. If a CTO or CEO is the domain expert they have to be in the room, but brief them first: their job is to answer questions when asked, not to lead. If they can’t hold that, run the session without them and walk them through the output afterwards. A dominated room produces one person’s model, not a shared one.
• Spectators. Anyone “just wanting to observe” is taking up airtime and absorbing attention. Either they participate or they’re not in the room.

Structure

Phase	Duration	Materials	Key question
Arrivals, intro, ground rules	15 min	—	“What are we doing and why?”
Chaotic exploration	20 min	Orange notes only	“What happens?”
Timeline	30 min	Orange + pink	“What order? What’s wrong?”
Break	10 min	—	—
Commands & actors	20 min	Blue + yellow	“What triggers it? Who does it?”
Hotspots	30 min	Pink clusters	“What scares us most?”
Wrap-up, owners, next steps	15 min	—	“Who owns what next?”
Buffer	20 min	—	—
Total	2h 40min inside a 3-hour block

The four working phases are 100 minutes. The remaining hour is the unglamorous stuff: late arrivals, the intro, the mid-session break, the wrap-up, and the conversations that run long. Don’t try to fill the 20 minutes of slack — you’ll need it.

Collaborations

The session alternates between silent writing and active argument. Juniors go first to set safety. Everyone writes, then everyone talks. The facilitator intervenes when one voice dominates, pairs people when the room has gone lopsided, and calls out the dynamic explicitly when implicit nudges aren’t working.

The key rhythm is write first, talk second. A dominant voice can’t shape what others think to write if they’re writing before the voice has a chance to speak. Once the wall is covered, argument is cheap because everyone has already committed their ideas in sticky-note form.

Facilitator Playbook

Phase 1 — Chaotic exploration (20 min)

Before the first note goes up, do two things that look trivial and aren’t.

Set the safety. Say it out loud:

“The only rule for this phase is that every note is valid. Duplicates are fine, half-formed ideas are fine, things that might be wrong are fine — that’s exactly what we’re here to find. If you’re not sure, write it anyway.”

Then name the junior-most person in the room:

“Jas, what’s the first event you can think of?”

Let them go first. You’ve just told the room that juniors go first, and that safety isn’t a promise — it’s a pattern.

Set the granularity. Put two example events on the wall yourself so people can see the level. Not “Customer Interacts With System” (too abstract), not “User Moves Mouse” (too fine). Aim for things a domain expert would say out loud:

“Payment Submitted.” “Box Packed.” “Alert Fired.” “Deployment Rolled Back.” “Certificate Expired.”

Now introduce the orange notes. These are domain events — things that happened, written in past tense. Past tense is the forcing function; it stops people from describing what should happen.

Give the one instruction:

“Write silently. Get everything you can think of onto orange notes and onto the wall. Don’t worry about order. Don’t worry about duplicates. We’ll sort it out later.”

Set a timer for 20 minutes. No talking until it goes off.

What to watch for:

• Someone talking instead of writing. Gently redirect: “Get it on a sticky note.”
• Someone waiting for permission or checking what others wrote. Reassure: “Duplicates are gold. Write yours anyway.”
• One person filling the wall with 30 notes while others have 3. This usually sorts itself out in phase 2, but keep an eye on it.
• Someone reaching for a pink note already. “Good instinct — hold that thought. We’ll get to problems shortly.”

By the end of 20 minutes you should have 40–80 orange notes. Some will be duplicates, some will contradict, some will make no sense yet. That’s exactly right.

Phase 2 — Timeline (30 min)

Now everyone talks. The job is to arrange the orange notes left-to-right in roughly chronological order.

Open it with:

“Let’s put these in order. Talk to each other. If you disagree about where something goes, that’s interesting — put a pink note on it and we’ll come back.”

What to watch for:

• One person placing all the notes while everyone else watches. This is the most common failure mode. If the domain expert is confidently placing everything unchallenged, the session is becoming a lecture. Pair a developer with the domain expert and ask them to walk a specific section together.
• No pink notes appearing. This doesn’t mean there are no disagreements — it means they’re hidden. Prompt directly: “Is there anything on this wall that surprises you?” Or ask someone to walk a section and explain it to someone from a different discipline.
• Rabbit holes into solution design. “That’s a great implementation idea — park it on a separate note. We’re still mapping what happens, not how to build it.”
• Parallel flows emerging. Let them spread vertically into swim lanes. A deployment flow and a rollback flow can share a wall.

Merge obvious duplicates. Leave ambiguous ones — if two notes might be the same event, that’s a conversation worth having.

Phase 3 — Commands and actors (20 min)

Hand out blue and yellow notes. For each event, identify:

• The command that triggered it (blue) — “Submit Payment”, “Run CI Pipeline”, “Trigger Failover”
• The actor who performed the command (yellow) — a person (“Customer”, “Support Lead”), a role (“On-Call Engineer”), a system (“Stripe Webhook”, “GitHub Actions”), or a scheduled job (“Nightly Billing Cron”, “4am Health Check”)

Place blue notes below the orange event, yellow notes above. Automated and scheduled actors are first-class here. A cron job, a webhook, a monitoring alert, a scheduled Lambda — all actors. Labelling them as such is how you surface the parts of the system that run without anyone watching.

What to watch for:

• “The system” on too many yellow notes. Push for specificity: “Which system? Automated or manual? What happens when it fails?”
• One person’s name on multiple recurring events. That’s a scaling bottleneck. Don’t solve it now — pink note it.
• Commands nobody can explain. “Who decides this?” followed by silence is extremely valuable. Pink note.

Phase 4 — Hotspots (30 min)

Gather around the pink notes. These are the most valuable output of the session — each one is a misunderstanding caught early, a question that needs answering, or a complexity that wasn’t visible before.

Cluster the pink notes into themes. Common clusters:

• Business or technical rules nobody has defined
• Processes that depend on one person
• Places where different people have different mental models
• Scaling bottlenecks
• Edge cases and failure modes

For each cluster, briefly:

• Is this something to resolve before we can build?
• Is this something to defer and revisit later?
• Who owns finding the answer?

Don’t try to solve everything in the session. The goal is to identify hotspots and assign ownership, not to resolve them on the spot.

What to watch for:

• Trying to solve a hard problem in-session. Time-box each cluster to 5 minutes. If it needs more, it needs its own session.
• Important pink notes being dismissed. “Oh, that’s an edge case” is often wrong — edge cases are where domain complexity lives.
• Energy dropping. Last phase, people are tired. Keep it brisk: name the cluster, capture who owns it, move on.

Steering When It Goes Sideways

Named failure modes. Each has a symptom, a recovery move, and a threshold where you stop the session rather than limp through.

The silent room. Nobody is writing or talking.   Recovery: The prompt is too abstract. Make it concrete: “What’s the first thing that happens when a new customer signs up?” One specific question gets things moving.   Stop if: 20 minutes in and the wall is still empty. Scope is wrong, people are wrong, or there’s a political problem you haven’t named.

The lecture. One domain expert explains while everyone listens politely.   Recovery: Pair people up, give each pair a section of the wall, ask them to walk it together.   Stop if: Two pairs in and it’s still the same voice. The session is producing one person’s model.

The argument. Two people disagree about how something works.   Recovery: Let it play out for 2–3 minutes. This is often the session working. If it’s not resolving, pink note it: “We disagree about this — let’s capture both versions.”   Stop if: The argument has gone personal. Take a break; come back only if the air has cleared.

The solution-jumper. Someone keeps designing the architecture instead of mapping the process.   Recovery: “Great implementation idea — park it on a separate note. Right now we’re mapping what happens, not how to build it.”   Stop if: They can’t hold the distinction after a third prompt. They belong in a design session, not this one.

The missing person. Halfway through, you realise nobody in the room knows how a key part of the process works.   Recovery: Pink note it with a name: “Need to talk to [person] about [topic].” Don’t guess.   Stop if: Multiple key parts are owned by people who aren’t in the room. You’re storming without the right participants — reschedule.

The political silence. A senior is in the room and the juniors have stopped writing.   Recovery: Quietly ask the senior to step out for a “call” (brief them first); or reframe the phase with a hard rule that everyone writes at least 5 notes in silence, no exceptions; or pair each junior with a peer away from the senior.   Stop if: None of the above shifts the dynamic. Thank everyone, photograph what’s on the wall, and reschedule with a different invite list. A short cancelled session is a better signal than a long wasted one.

Consequences

Benefits

• A shared mental model that persists long after the sticky notes come down
• Named vocabulary that shows up in user stories, Slack, code, and hallway conversations
• A prioritised hotspot list — the questions you didn’t know you needed to ask
• Misunderstandings caught on paper, not in production

Costs

• 15–24 person-hours for a 3-hour session with 5–8 people
• Coordination cost of getting the right people in one room
• Political risk when hierarchies get flattened
• Reputational cost if a first session flops before a sceptical team

Failure modes

• The session produces one person’s mental model instead of a shared one
• Scope was too abstract and the wall stays sparse
• The wrong people in the room — or the right people missing
• Arguments turn personal instead of staying on the work

Stop-the-session signals

• 90 minutes in, the wall is mostly blank
• Everyone is deferring to one person and pairing hasn’t shifted it
• Arguments have gone personal

Ending early is not failure. Wasting another hour after the session is already broken is.

Worked Example

See Event Storming: Building Shared Understanding for the Greenbox team running their first Process Level session — including the moment Jas catches that “box packed” means two different things to warehouse and customer support, which becomes the pink note that reshapes a month of work.

Outputs & Follow-up

Facilitator’s close-out (same day, 24 hours)

• Panoramic photographs of the wall. High resolution, good lighting, multiple shots. Bad photos of a good wall are a real loss.
• Transcribed event list and hotspot list in a shared document.
• A short summary message to all participants: “here’s what we found, here’s what happens next.”

The product owner’s week

This is where the pattern earns its cost, and the work is mostly yours.

• Turn each event into a vocabulary entry. “Box Packed” becomes a ubiquitous term — one specific thing, everyone uses it consistently, and it shows up in user stories, acceptance criteria, Slack, and the code.
• Triage the hotspots. Each cluster becomes one of: (a) work for this sprint, (b) a spike, (c) a follow-up workshop, (d) a conversation. You need a decision rule: resolve the ones that block the next sprint, defer the ones that don’t, schedule workshops for the ones that are genuinely unknown.
• Book the follow-ups. Top 2–3 hotspot clusters become Example Mapping sessions, assumption-testing spikes, or design spikes. Don’t let them sit.
• Write the stakeholder one-pager. Lead with the surprises, not the events. “We discovered three things we were assuming wrong” is more useful than “here’s a list of 18 events.”
• Walk the wall with anyone who couldn’t attend. Their perspective may surface hotspots the original group missed.

Ongoing

• Keep the wall or photos visible while the work is active. Teams that can glance at the event map during standups and planning make better decisions than teams working from memory.
• Update the map when the process changes. Event Storming is a snapshot. Snapshots go stale.

Related Patterns

• Example Mapping — hotspots from an Event Storming session often become the input to an Example Mapping session. Event Storming finds the questions; Example Mapping turns them into rules and examples.
• Impact Mapping — Event Storming describes how things happen now; Impact Mapping describes what you want to change and why. Run Impact Mapping first when you’re choosing what to build; run Event Storming first when you’re understanding what exists.
• User Story Mapping — after an Event Storming session, a User Story Mapping session turns the timeline into a prioritised release plan.
• Retrospectives — a post-incident Event Storming is a retrospective with sticky notes on a wall instead of a conversation around a table. Use it when the incident crossed enough systems that a conversation can’t hold the shape.
• Threat Modelling — the actors-and-commands view is an input to threat modelling. “Who triggers this command, and what happens if they’re not who they claim to be?” is the bridge.