A team runs a workshop where people write things on orange sticky notes in past tense (like 'Order Placed' or 'Payment Failed') and stick them on a long roll of paper in a rough timeline, with all the chairs removed from the room. What is this workshop technique called and what is its core mechanism?
answer
- orange = past-tense domain events
- unlimited modeling surface
- law of mobility (no chairs)
- parallel silent writing
- collapses org chart for a few hours
basics
~20 sThis is Event Storming - a workshop where people from business and tech stand at a wall and write domain events (things that happened) on orange sticky notes in time order, to quickly build a shared picture of how a system or business process really works.
solid answer
~50 sEvent Storming is a low-tech, high-bandwidth collaborative modeling technique invented by Alberto Brandolini. A cross-functional group - domain experts, developers, testers, product people - stands at an unlimited modeling surface (a long roll of paper or a big whiteboard) and writes domain events in past tense ('Order Placed', 'Shipment Delayed') on orange sticky notes, placing them roughly left-to-right in the order they occur. The point isn't precision up front; it's rapid, parallel externalization of everyone's mental model so gaps, disagreements, and unknown unknowns surface immediately - something a sequential meeting or a document review rarely achieves. Once the event timeline is roughly laid out, the group adds other elements (commands, actors, systems) to explain how each event gets triggered. The output is a shared, visual model of the business process that becomes the starting point for deeper design work.
go deeper
Should be able to describe the basic mechanic - sticky notes, past-tense events, timeline - and explain in plain language why getting everyone in a room beats a written requirements doc.
Should additionally explain the facilitation mechanics (unlimited surface, no chairs, parallel silent writing) and why each exists, not just that they exist.
Should connect the technique to the specific organizational failure it fixes (siloed, serially-relayed knowledge) and be able to facilitate or co-facilitate a session, spotting when the room has gone quiet or a voice is dominating.
Should be able to decide when NOT to run it, size the session correctly for the domain's actual complexity, and integrate its output into a broader discovery/design roadmap rather than treating it as a one-off ritual.
## What Event Storming is, and why the room looks like that Event Storming is a facilitated group-modeling technique for exploring a business domain by building a timeline of **domain events** — things of business significance that have already happened, phrased in past tense on orange sticky notes (e.g. `Order Placed`, `Payment Declined`, `Shipment Delayed`). The mechanics matter as much as the notation. - **An unlimited modeling surface.** The session happens at an "unlimited modeling surface" — literally a long roll of butcher paper taped to a wall, or a very large whiteboard — because a fixed-size surface like a single flipchart page unconsciously limits how much of the process people are willing to model; give people miles of paper and they stop self-censoring scope. - **Chairs are removed from the room.** Brandolini calls this the "law of mobility": standing keeps people physically near the wall and each other, which increases the rate of spontaneous side conversations that resolve ambiguity on the spot, rather than people waiting to be called on. - **A deliberately cross-functional group.** Developers, testers, product owners, support staff, and, most importantly, domain experts who live the process day to day — because no single role holds the full picture, and each role notices different gaps when they see the timeline forming. ## How a session runs The session typically opens with a chaotic exploration phase: everyone grabs a stack of orange stickies and writes down every domain event they can think of, silently and in parallel, then walks up and places them on the timeline without waiting for permission. This parallel, low-friction writing is the core trick. | Meeting shape | What an hour of it yields | |---|---| | A normal meeting is serial — one person talks at a time | a room of 20 people can surface maybe 20 minutes of one person's knowledge in an hour | | Event Storming is parallel | it lets 20 people externalize their knowledge simultaneously | - Duplicate events get merged. - Conflicting phrasings for the "same" event reveal that two departments actually mean different things by the same word. - Gaps in the timeline get filled in as people notice "wait, how did we get from A to C, what happened at B?" ## The problem it solves The problem this solves is the failure mode of traditional requirements-gathering: a business analyst interviews stakeholders one at a time, writes a document, and hands it to developers, who each fill remaining gaps with their own assumptions. Every hand-off is a lossy translation — the classic "game of telephone" — and specialists in silos each hold a different partial model that never gets reconciled until a bug or a missed requirement forces it into the open, usually late and expensively. By collapsing the org chart into one room for two to four hours, Event Storming forces the reconciliation to happen at the cheapest possible point: **before any code or even any formal spec exists**. ## The trade-off The trade-off is **cost and discipline**. - Getting the right mix of 15-25 people together for half a day is genuinely expensive and hard to schedule, doubly so across departments or time zones, or when running remotely on a virtual whiteboard tool, which recovers the visual/parallel-writing benefit but loses the "law of mobility" energy of a physical room. - The output is also intentionally informal — an enormous wall of stickies is not a specification, does not replace deeper technical design, and can create a false sense of "we're done" the moment the paper looks full, when in fact the session has only produced raw material for further Process- or Design-level modeling. ## Recognizable failure modes In production, the technique fails in recognizable ways. 1. A dominant voice ends up narrating the whole timeline while quieter domain experts, who often hold the most valuable edge-case knowledge, disengage. 2. The group jumps prematurely into solution-mode ("so this should be a microservice") instead of staying in the pure problem space. 3. The session is treated as a one-off event — nobody photographs, transcribes, or revisits the wall before it's taken down, so the reconciled shared understanding evaporates within a week. ## A worked scenario A widely cited illustrative scenario, close to the ones Brandolini uses when teaching the technique, is an e-commerce order lifecycle: `Order Placed` -> `Payment Authorized` -> `Inventory Reserved` -> `Order Shipped` -> `Delivery Failed`, with each event exposing questions like "who triggers the retry when Delivery Failed happens?" that a document review would likely have missed.
- Who invented Event Storming and roughly when?Alberto Brandolini popularized Event Storming around 2013, building on ideas from Domain-Driven Design and lightweight collaborative modeling; he later formalized the different variants (Big Picture, Process, Design Level) and the 'law of mobility' facilitation principles in his writing and workshops.
- Why orange specifically for domain events, and does the color scheme matter?The exact color is a convention, not a law - what matters is that the whole team consistently uses one distinct color per element type so the board is instantly scannable; Brandolini's original palette has just become the de facto standard because most training material and tooling reuses it.
- Can Event Storming be run remotely?Yes, using virtual whiteboards like Miro or Mural, and it recovers most of the parallel-writing benefit; what's lost is the physical 'law of mobility' energy and the ease of spontaneous side conversations, so remote facilitators typically need more explicit turn-taking structure to compensate.
- How long does a Big Picture session typically take?Commonly half a day to a full day for a moderately complex domain; very large domains are sometimes split into multiple half-day sessions per sub-area rather than one marathon session, since attention and information density both degrade past a few hours.
Like a jigsaw puzzle where every person at the table holds a handful of pieces from a different box; instead of describing their pieces to one person who assembles the puzzle alone, everyone dumps their pieces onto one huge table at once and starts connecting edges together, so the full picture emerges in minutes instead of days of relayed descriptions.
saying these in an interview costs you the question
- describes it as just 'a workshop where you write user stories'
- thinks the sticky notes are the deliverable/spec rather than raw exploration material
- would run it with only engineers and no domain experts in the room
- doesn't know why chairs are removed / dismisses it as a gimmick
- conflates domain events on the board with the Domain Events pattern implemented in code