For the story in action, see Event Storming: Building Shared Understanding — the Greenbox team running a Process Level session on their first subscription flow.
About Event Storming
Event Storming is a sticky-note technique invented by Alberto Brandolini in 2013 for getting people with different knowledge of a process to build one shared mental model of it. Everyone stands in front of a long wall; each person grabs a pad of orange sticky notes and writes things that happened — in past tense, one per note — and sticks them on the wall. “Payment Submitted.” “Box Packed.” “Alert Fired.” “Deployment Rolled Back.” The wall becomes the shared surface. The sticky notes become 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.
Event Storming comes in three levels. This post covers Process Level — the default, and the one most teams reach for most of the time. The other two:
- Big Picture — a whole domain or large subsystem, half a day to several days, mixed business and IT. Run it when you need cross-team alignment on how an entire product works.
- Software Design — the code boundary around a process, 2–4 hours, architects and dev leads. Run it after Process Level has clarified the flow and you’re ready to design the code.
If you’re not sure which you need, start here. Process Level handles most real problems — a specific process, flow, pipeline, incident, or feature area that needs shared precise understanding.
Intent
Map one specific process — a flow, a pipeline, a user journey, an incident, a billing cycle — as a precise sequence of events, commands, and actors, so the people building or operating it share one mental model.
Also Known As
Brandolini calls this Process Modelling EventStorming in his book. I use “Process Level” in this series to avoid a name collision with traditional process modelling. Sometimes shortened to just “Event Storming” when context makes the level clear.
Motivation
You have a specific process that’s unclear, under-documented, or about to be built, and the team holding the work doesn’t share a precise model of it.
A team is about to build a subscription billing flow. The product owner thinks payment happens on signup, once, for a fixed amount. The developer has been coding it that way. The operations lead knows — but hasn’t said — that each subscription is billed a variable amount on a recurring cycle, and the amount can’t be calculated until the day of billing. Three mental models of one flow. A week from now, either the PO or the dev is going to rewrite half their work, unless the models get reconciled first.
Or: an on-call engineer is handed an existing billing flow to maintain. Nobody has ever drawn it. There’s code, there’s cron, there’s a Stripe integration, and there are three edge cases handled in three different places by three different people who’ve since left. A Process Level session is the cheapest way to rebuild the shared model before something breaks at 3am.
Or: a team is investigating a production incident that crossed three services. The timeline exists in Slack, git history, and people’s memories. A Process Level session with a wall and orange sticky notes turns those fragments into one picture.
Process Level is the workshop you reach for when you have one specific thing that needs one precise, shared understanding.
Applicability
Use when:
- You’re about to build a specific process and want everyone aligned before code
- You’re inheriting or re-learning a process that already exists
- You’re investigating an incident, a migration, or a workflow that keeps surprising people
- You’ve zoomed in from a Big Picture session to a specific hotspot
- A piece of work is about to cross multiple people’s areas and you want to spot the mismatches early
Don’t use when:
- The scope is small and well-understood — one CRUD screen, one isolated function
- You don’t have access to people who know how the process actually works
- The team genuinely shares a strong, tested model of the flow already
- You’re trying to map a whole domain — use Big Picture instead (publishes 13 April)
- You’re ready to design the code — use Software Design Event Storming instead
Participants
Facilitator. Does not participate in content — their job is to manage the process, ask questions, keep things moving, and spot the failure modes early. Ideally someone who’s run a Process Level session before.
Domain expert(s) — the people who know how the process actually works. For a billing flow, the finance lead. For a deployment pipeline, the SRE who runs it. For an incident review, the engineers who responded. You usually need one or two, not a whole crowd.
Developers — at least one, including a junior if you have one. Juniors ask the questions seniors have stopped asking, and they catch mismatches between the model in the room and the model in the code.
Product or design — whoever will turn the output into stories 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: 4–8. Smaller than Big Picture because the scope is tighter. Fewer than 4 and the conversation is too thin; more than 8 and the wall gets crowded and voices start overlapping.
Who to leave out:
- End users and customers. People self-censor around the people they serve. Interview users separately, bring their words into the room on a sticky note.
- Senior leaders who can’t stop correcting. If a senior is the domain expert, brief them first: their job is to answer when asked, not to lead. If they can’t hold that, run without them.
- Spectators. Anyone “just observing” absorbs airtime without contributing. Either they’re in or they’re out.
Structure
| Phase | Duration | Materials | Key question |
|---|---|---|---|
| Arrivals, intro, ground rules | 15 min | — | “What are we doing and why?” |
| Chaotic exploration | 20 min | Orange notes | “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.
A note on note colours. The basic Process Level session uses four colours: orange events, blue commands, yellow actors, pink hotspots. That’s what Brandolini’s original workshops used — it’s plenty for a first session, and it’s enough to surface the big mismatches that matter.
Once a team has run a few sessions and is ready for more structure, Brandolini’s formal Process Modelling adds two more colours:
- Purple — policies. Rules that turn an event into a command. “When a payment fails, retry once then notify the customer.” Policies live between events and commands.
- Green — read models. The information an actor consults before making a decision. “The on-call engineer checks the current error rate before deciding whether to page.” Read models live alongside the actors who consume them.
These are genuinely powerful, but they add complexity and slow the session down. Skip them on your first few Process Level sessions — get comfortable with the four-colour basics first, then add purple and green when the team asks for them.
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 by name:
“[Junior’s name], what’s the first event you can think of? Doesn’t have to be the start of the process — just the first one that comes to mind.”
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. 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 about this process 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: “Get it on a sticky note.”
- Someone waiting for permission. “Duplicates are gold. Write yours anyway.”
- One person filling the wall while others have three notes. 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.”
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 chronological order.
Open it with:
“Let’s put these in order. Talk to each other. If you disagree about where something goes, 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. The most common failure mode. Pair a developer with the domain expert and ask them to walk a section together.
- No pink notes appearing. Disagreements are hidden, not absent. Prompt: “Is there anything on this wall that surprises you?”
- Rabbit holes into solution design. “Great implementation idea — park it. We’re mapping, not building.”
- Parallel flows emerging. Let them spread vertically into swim lanes. A rollout 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. Introduce them one at a time — if you drop both colours on the table at once, people grab whichever is closest and the wall gets noisy.
Blue first — commands. For each event, what action caused it?
“Blue notes go below the orange event. They’re the command that made it happen. ‘Submit Payment’ causes ‘Payment Submitted’. ‘Run CI Pipeline’ causes ‘Build Started’. Every event has a command somewhere, even if the command is a scheduled job.”
Yellow next — actors. Who performed the command?
“Yellow notes go above the orange event. They’re the actor — a person, a role, a system, a scheduled job. Be specific. ‘Customer’ is fine; ‘the system’ is not — which system? If it’s automated, name the job.”
What to watch for:
- “The system” on too many yellow notes. “Which system? Automated or manual? What happens when it fails?”
- Business rules hiding inside a command. “Wait, that command only runs sometimes — what decides?” Pink note it — that’s a Decision Tables candidate, and it’s a sign the team may want to add purple (policy) notes on a future session.
- One person’s name on multiple recurring actors. Scaling bottleneck. Pink note.
- Commands that nobody can explain. “Who decides this?” followed by silence is extremely valuable. Pink note.
By the end of this phase, each event has a command below and an actor above. The wall has three horizontal bands — actors across the top, events in the middle, commands below — and the shape of the process is suddenly visible.
Phase 4 — Hotspots (30 min)
Gather around the pink notes. These are the most valuable output — 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:
- 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:
- Is this something to resolve before we can build?
- Is this something to defer?
- Who owns finding the answer?
Don’t try to solve everything in-session. Identify hotspots and assign ownership.
What to watch for:
- Trying to solve a hard problem in-session. Time-box 5 minutes per cluster.
- Important pink notes being dismissed. “Oh, that’s an edge case” is often wrong.
- Energy dropping. Keep it brisk: name the cluster, capture the owner, move on.
Steering When It Goes Sideways
Named failure modes. Each has a symptom, a recovery move, and a threshold where you stop 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 payment hits our system?” 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 expert explains while everyone listens politely. Recovery: Pair people up, give each pair a section of the wall. 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 for 2–3 minutes. This is often the session working. If it’s not resolving, pink note it. Stop if: The argument has gone personal. Break; resume only if the air has cleared.
The solution-jumper. Someone keeps designing the code instead of mapping the process. Recovery: “Great implementation idea — park it.” Stop if: They can’t hold the distinction after a third prompt. They belong in a Software Design session, not this one.
The missing person. 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].” Stop if: Multiple key parts are owned by people not in the room. Reschedule with the right attendees.
The political silence. A senior is in the room and the juniors have stopped writing. Recovery: Ask the senior to step out for a “call” (brief them first); or enforce “everyone writes 5 notes in silence, no exceptions”; or pair juniors with peers away from the senior. Stop if: None of the above shifts the dynamic. Thank everyone, photograph what’s on the wall, reschedule.
Consequences
Benefits
- A precise shared model of one process that persists long after the wall comes down
- Named vocabulary for that process — showing 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
- Policies and read models made explicit, often for the first time
Costs
- 12–24 person-hours for a 3-hour session with 4–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 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 the junior developer 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.
- Transcribed event list, command list, policy 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.
- Triage the hotspots. Each cluster becomes one of: (a) work for this sprint, (b) a time-boxed investigation, (c) a follow-up workshop, (d) a conversation. Resolve the ones that block the next sprint; defer the rest.
- Book the follow-ups. Top 2–3 hotspot clusters become Example Mapping sessions or time-boxed investigations. 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.
- Update the map when the process changes. A Process Level model is a snapshot, and snapshots go stale.
Related Patterns
- Big Picture Event Storming (publishes 13 April) — zoom out when you’re trying to understand a whole domain and need cross-team alignment before you can pick a specific process to focus on.
- Software Design Event Storming (publishes 12 April) — zoom in after Process Level has clarified the flow and you’re ready to model the code as aggregates and bounded contexts.
- Example Mapping (publishes later this week) — hotspots from a Process Level session often become the input to an Example Mapping session. Process Level finds the questions; Example Mapping answers them as rules and examples.
- Retrospectives — a post-incident Process Level session 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.