Event Storming
Created by Alberto Brandolini, Event Storming is a collaborative modelling workshop that brings together developers and domain experts to explore a complex business domain at speed. Participants model a system or business process by placing colour-coded sticky notes on a timeline: orange for domain events (things that happen), blue for commands (what triggers them), yellow for actors, and red for hotspots (areas of confusion or conflict).
Facilitation script
- 1
Prepare the space and brief the room: hang at least six to ten metres of continuous paper, remove the chairs so everyone stays standing, and explain the colour code — orange for domain events in past tense ('Order Placed', 'Payment Failed'), blue for commands, yellow for actors, red for hotspots. Frame the rule: 'Write what happens, not what should happen.'
20 min - 2
Launch chaotic exploration: everyone writes and posts orange event notes simultaneously, anywhere on the wall, without asking permission or agreeing order. Resist the urge to organise — seed quiet stretches of the wall with prompting questions ('what happens after payment fails?') and break up any queue forming to discuss instead of write.
45 min - 3
Enforce the timeline: have the group sort all events chronologically left to right, merging duplicates as they go. When an ordering dispute drags past a minute, put a red hotspot on it and move on — the disagreement is a finding, not a blocker.
40 min - 4
Walk the timeline aloud: pick a narrator to tell the whole story from the first event to the last while the room corrects them. Every gap becomes a new orange note; every 'well, actually' becomes either a correction or a red hotspot.
30 min - 5
Add blue commands and yellow actors. For each significant event ask: 'What triggered this, and who issued it?' Watch for events with no clear trigger or actor — those usually hide automation, batch jobs, or a department nobody invited.
45 min - 6
Identify bounded contexts: look for places where the vocabulary shifts, responsibility changes hands, or the same word means different things, and draw boundaries around those clusters. Name each context with the group — the names will follow the model into design discussions.
35 min - 7
Close on the hotspots: read every red note aloud, and for each one assign an owner and a next step — a follow-up conversation, a data check, or a deeper Process Level session. Photograph the entire wall in overlapping sections before anyone touches a note.
25 min
Tips
The mess is part of the process — the first pass will be chaotic.
That's correct.
Hotspots are the most valuable output: they mark the places where assumptions haven't been tested.
Include both domain experts and technical staff — the mix is essential.',
Common pitfalls
Tidying too early — imposing order during chaotic exploration kills the parallel discovery that makes the method fast; the mess is the point
Letting the room debate every disagreement to consensus instead of parking it as a red hotspot and keeping the timeline moving
Accepting imperative or future phrasing like 'Send invoice' on orange notes — events must be past-tense facts, or commands and events blur into mush
Skimping on wall space — when the paper runs out, people compress the timeline and quietly stop adding events, and the model loses exactly the detail you came for
Variations
Run a 'Big Picture' Event Storming (whole business) before a 'Process Level' session (single flow). Use digitally with colour-coded cards in Miro for distributed teams.
Where it fits
When to use it
A legacy system nobody fully understands must be modernised or split, and the knowledge lives scattered across a few veterans' heads
Developers and domain experts keep talking past each other, and the team needs one shared end-to-end picture of the business process before designing software
A monolith is being carved into services or bounded contexts and the boundaries should come from the domain itself, not the org chart
A cross-departmental process fails at the handoffs and no single person can say what actually happens between 'order placed' and 'money in the bank'
When not to use it
The domain experts cannot attend — running it with developers alone just documents existing assumptions; postpone until the business side is in the room
The process is simple or linear enough to capture in an hour — a user journey map or plain flowchart does the job with far less ceremony
Only a two-hour slot is available — below roughly half a day the group barely finishes chaotic exploration; book the time or scope down to one narrow flow
The goal is prioritising or deciding rather than understanding — Event Storming produces shared knowledge and hotspots, not a ranked backlog
Related methods
Frequently asked questions
How long does an Event Storming workshop take?▾
Plan at least half a day; a full day (up to eight hours) is common for a Big Picture session covering a whole business line. Complex domains often need a sequence: one Big Picture day, then shorter Process Level sessions on the flows that produced the most hotspots.
How many people should attend an Event Storming session?▾
Between 6 and 30, and the mix matters more than the number: you need the people who know the domain — operations, sales, finance, support — alongside the developers who will build against it. A session without domain experts produces a confident model of the wrong system.
Can Event Storming be run remotely?▾
Yes, on a shared whiteboard with colour-coded digital stickies and a visible legend, since nobody can glance at a physical note colour. Split the work into two half-day blocks rather than one long call, and use a raised-hand or marker convention for hotspots — the energy cues a facilitator reads in the room are the main thing you lose.
What is the difference between Event Storming and user journey mapping?▾
A user journey map follows one persona's experience through touchpoints and emotions, and is aimed at improving that experience. Event Storming maps everything that happens in the domain — including back-office and system events no customer ever sees — and is aimed at shared understanding and software boundaries. Journey maps make good inputs to an Event Storming wall, not substitutes for it.
What materials and preparation does Event Storming need?▾
A continuous paper roll of six to ten metres, generous stacks of orange, blue, yellow, and red sticky notes, and a marker per person. Prepare a one-sentence scope statement ('from enquiry to paid invoice') and the invite list — but do not pre-draw any model; arriving with a diagram defeats the discovery.
Plan your next workshop with AI
Workshop Weaver helps you combine methods like Event Storming into a complete, timed agenda in minutes.
Try it freeMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices.