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?

## 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.