The Workshop: Event Storming

This is the overview. For the story of Event Storming in action, read Event Storming: Building Shared Understanding — the Greenbox team running their first session. If you already know which level you want, jump straight to the sub-pattern you need.

Intent

Build one shared mental model of a process by mapping it — as a chronological wall of things that happened — with everyone who knows a different part of it in the same room at the same time.

Also Known As

Brandolini calls the middle level Process Modelling EventStorming; I use “Process Level” in this series to avoid a name collision with traditional process modelling as a discipline. Commonly confused with three other techniques:

• Traditional process modelling (BPMN, flowcharts, swim lanes) — these document an agreed process using a formal notation. Event Storming is discovery: it surfaces what people actually think, including where they disagree, and the output isn’t a diagram anyone could read outside the room.
• User journey mapping — maps the experience from the customer’s side. Event Storming maps the system from the inside, including the parts the customer never sees.
• Value Stream Mapping — a lean technique that measures flow, waste, and cycle time through a pipeline. VSM asks “where does time get wasted?”; Event Storming asks “do we agree on what happens?” Run VSM when you know the process and want to optimise it; run Event Storming when you’re not yet sure everyone means the same thing.

Motivation

The team has different mental models of the same process and nobody has noticed.

The warehouse lead thinks “Box Packed” is the moment the lid goes on. Customer support thinks it’s the moment the box leaves the building. The developer thinks it’s the database flag flipping. Three definitions, one name. When the product owner writes a story that says “notify the customer when the box is packed,” everyone nods. Then the emails go out two hours early and nobody can work out why.

This is the shape of the problem Event Storming solves. The symptoms look like bugs, rework, missed requirements, and late-night arguments about whose code is wrong. The cause is upstream: people carrying different models, each model slightly wrong in a different place, and nobody ever putting the models next to each other to see the gaps. The longer it goes on, the more the team builds on the mismatch — stories referencing the ambiguous term, tests baking in one interpretation, Slack threads where the same words mean different things to the people replying.

Event Storming exists to put the models next to each other, cheaply and early, before the mismatch gets scaffolded on for months.

The three levels

Brandolini distinguishes three levels that share mechanics but differ in scope, participants, duration, and output. Each has its own sub-pattern in this series.

Level	Scope	Participants	Duration	Output
Big Picture (coming 13 April)	A whole domain or large subsystem	5–20, mixed business + IT	Half a day to several days	Cross-team alignment, a map of hotspots worth zooming into
Process Level (default)	One specific process, flow, or pipeline	4–8, focused	2–3 hours	A precise model of one flow with events, commands, and actors; a prioritised hotspot list
Software Design (coming 12 April)	The code boundary around a process	3–6, architects + devs + domain expert	2–4 hours	Aggregate boundaries, bounded contexts, command/event APIs per component

All three use events (orange sticky notes, past tense) as the backbone. The levels add different supporting elements:

• Big Picture adds hotspots, systems, and people markers — you’re trying to see the shape of a whole domain at a glance.
• Process Level adds commands and actors — you’re trying to understand how one flow really works, including what triggers each step and who or what performs it. (Mature sessions can also add policies and read models, but most first sessions skip those.)
• Software Design adds aggregates and bounded context boundaries — you’re turning the flow into a system design.

How to decide which level

Start with this three-question rule. If you answer the first yes, run that level; otherwise move down.

1. Are you trying to understand a whole domain you don’t yet have a shared picture of? Run Big Picture (the sub-pattern publishes 13 April). This is rare and expensive — it’s for the start of a major initiative, a new team onboarding, or an organisation that has drifted into multiple mental models across departments.

2. Do you have a specific process, flow, or pipeline that needs a shared, precise understanding? Run Process Level. This is the default. Most teams, most of the time, are here. You have a concrete thing you’re building, operating, or investigating; you need everyone to see it the same way.

3. Do you already have a clear Process Level model and need to turn it into a software design? Run Software Design (the sub-pattern publishes 12 April). This is the zoom-in after Process Level has clarified the flow and you’re ready to model the code.

You can work the levels as a ladder — Big Picture first to find the hotspots, Process Level on each hotspot, Software Design on the one you’re about to build. Most of the time you skip the top and start at Process Level with one specific problem.

When not to use any of them

• The scope is small and well-understood — a single CRUD screen, a password reset flow, a log format change.
• You can’t get the right people in the room.
• The team genuinely already shares a strong, tested mental model of the process.

If you’re not sure whether you need one, you probably do. Teams rarely regret running a session; they frequently regret skipping one.

Related Patterns

• Example Mapping — hotspots from an Event Storming session often become the input to Example Mapping. 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 — turns an Event Storming 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 round 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 from a Process Level session is one of the inputs to threat modelling.

(The sub-patterns for each of these workshops publish over the coming weeks.)