In short
Event storming is a collaborative workshop method with which business experts and developers jointly model a business area as a chronological sequence of events. Instead of starting with data models or forms, the group collects all relevant domain events on coloured sticky notes along a long wall.
The format was invented by the Italian consultant Alberto Brandolini, who himself usually writes it as one word, "EventStorming".
The method comes from the field of domain-driven design (DDD) and is now regarded as one of the most widespread ways to make complex business logic visible before the first line of code is written. How event storming fits into a DDD project at a mid-sized company and when the effort pays off is described in detail in the article domain-driven design in practice.
What event storming is and where the method comes from
Brandolini presented the format on 18 November 2013 in his blog post "Introducing Event Storming". The core is already there: domain events on orange notes along a timeline, the triggering commands on blue notes in front of them, and then the search for aggregates "from the outside in". He also calls for a practically unlimited modelling space, if necessary with a large paper roll across the wall.
According to the English-language Wikipedia, the name came about at short notice during Vaughn Vernon's IDDD tour; before that, the approach was called "event-based modelling". Vernon also covers the method in his book "Domain-Driven Design Distilled" (2016). The format has developed considerably since 2013, as Brandolini himself points out in the note above his original post.
Today, the authoritative source is his book "Introducing EventStorming" on Leanpub. It is being published gradually and is still listed as not yet complete on the Leanpub page (as of October 2026). The official website eventstorming.com brings together additional information, training and format descriptions.
Why events instead of data models
A domain event describes a relevant business fact in the past tense: "quote sent", "order confirmed", "machine delivered". Sales, production, accounting and IT understand such sentences equally well. This lowers the barrier for business experts who have little use for UML or entity relationship diagrams. At the same time, the timeline forces sequences, dependencies and gaps to be addressed openly.
Brandolini describes the result as a behaviour-oriented model that fits well with DDD and event sourcing and helps to find context and aggregate boundaries. This is exactly what makes the method interesting for architectural decisions: anyone who understands when what happens in the business can cut software along these processes.
The three formats: big picture, process modelling, software design
Event storming is a family of formats at different altitudes. Three levels have become established in the community, described among others by the DDD Crew's glossary. You can go through them one after the other or use just one level, depending on which question is to be answered.
Big picture event storming
The big picture format maps an entire business area, often from the first customer contact to invoicing and service. The aim is a shared understanding across departmental boundaries and the uncovering of bottlenecks, contradictions and conflicts. The notation is deliberately kept lean: domain events, hotspots, actors, systems and opportunities. The DDD Crew's glossary mentions groups of 10 to more than 30 people at a shared paper roll.
Process modelling
Process modelling zooms in on a single process. Now a fixed grammar comes into play: an actor sees a read model with information and triggers a command. A system processes it and produces a domain event. A policy reacts to this according to the pattern "whenever X happens, then Y" and triggers the next command. This turns the rough timeline into a seamless process flow in which missing rules and handovers stand out.
Software design
The software design format is about concrete implementation within a delimited sub-area. The group adds aggregates, also called constraints in more recent usage, i.e. the places where business rules and consistency are enforced. Here it is mainly developers, architects and selected business experts who work together. Commands, events and responsibilities can be transferred very directly from this model into code, for example into an event-driven architecture.
Notation: which sticky note stands for what
The colours in event storming are conventions and not a binding standard. Some are considered "official" in the community, such as orange for domain events and neon pink for hotspots. Others vary depending on the facilitator, the material available and the tool. That is why every workshop wall needs a visible legend that is extended when new concepts appear.
In his article "EventStorming Core Concepts, Glossary and Legend", Kenny Baas-Schwegler describes the assignment that is common today, on which the following overview is based. The examples in the right-hand column come from a fictitious mechanical engineering scenario.
| Element | Usual colour | Meaning | Example |
|---|---|---|---|
| Domain event | Orange | Relevant business fact in the past tense | "Quote sent" |
| Command | Blue | Intention or action that triggers an event | "Approve quote" |
| Actor | Yellow, small | Person or role that triggers a command | Inside sales |
| Policy | Purple (lilac), large | Reaction rule following the pattern "whenever …, then …" | "When order confirmed, trigger production planning" |
| External system | Pink, wide | System outside the area under consideration | ERP, supplier portal |
| Read model | Green | Information an actor needs for a decision | Overview of free assembly capacity |
| Aggregate / constraint | Yellow, large | Place where business rules and consistency are enforced | Order, machine configuration |
| Hotspot | Neon pink / magenta | Open question, conflict or pain point | "Who approves special prices?" |
| Opportunity | Green | Improvement idea that comes up during modelling | "Offer spare parts ordering online" |
What stands out is the double use of green for read models and opportunities. In practice, opportunities mainly appear in the big picture and read models only in process modelling, so the two rarely get in each other's way. In any case, it is more important that all participants have the same legend in front of them than the exact colour. In addition, many teams mark pivotal events, i.e. key events, with a vertical line and separate parallel flows into swimlanes.
How an event storming workshop runs, step by step
For a big picture event storming, a sequence of phases has proven itself that Brandolini describes in his book and that facilitators adapt depending on the group. The following process shows the typical steps:
- Kick-off: the facilitator explains the goal and scope of the workshop and initially introduces only one building block, the orange domain event.
- Chaotic exploration: everyone writes down events in parallel and largely in silence and sticks them roughly on the wall. Order, duplicates and wording do not matter yet.
- Enforcing the timeline: the group sorts the events from left to right, merges duplicates and puts the wording into the past tense. Pivotal events divide the flow into phases.
- Marking hotspots: every open question, every contradiction and every conflict gets a pink note. Discussions are parked so that the group stays in the flow.
- Adding actors and systems: the roles and systems involved are added to the events, such as ERP, CRM or Excel lists.
- Walkthrough and reverse narrative: one person tells the story from left to right, the others correct it. When reading backwards, the group asks what must have happened before each event and so finds missing steps.
- Prioritising problems and opportunities: the participants vote on which hotspots and opportunities should be tackled first.
- Securing the result: photos of the wall, a list of the prioritised hotspots with owners and concrete next steps.
Preparation: room, wall, participants and duration
Event storming stands or falls with preparation. Three factors determine the quality: enough space, the right people and a realistic time frame.
Room and material
You need a long, free wall and a paper roll, because sticky notes tend to fall off wallpaper or glass. Add sticky notes in at least five colours, thick felt-tip pens for notes that can be read from a distance and a visible timer. Many facilitators clear tables and chairs out of the wall area so that the group stands and keeps moving. No presentation slides are needed.
The right people
Brandolini puts the rule of thumb like this: the room should contain people who ask the right questions and people who know the answers, plus neutral facilitation. For a mechanical engineering company, this means, for example, sales, design, work preparation, production, service, accounting and IT. If one area is missing, a blank spot remains on the wall that can become expensive later. At least one person with decision-making authority should be present.
Duration
There are no fixed requirements. Depending on scope, a big picture event storming needs half a day to a whole day, and several days for complex domains. Process modelling and software design usually take place in shorter, repeated sessions of a few hours, each focused on one process or sub-area. Plan generous breaks, because intensive modelling while standing takes energy.
Remote event storming with Miro and co.
Since distributed teams have become the norm, event storming often takes place on online whiteboards such as Miro, Mural or Conceptboard. Many of these tools offer ready-made templates with a legend. The advantages are obvious: unlimited space, no travel costs and a result that is immediately available digitally and can be processed further.
The disadvantages are just as real. The energy of a group in front of the wall is hard to create online, parallel conversations are hardly possible and screen fatigue sets in early. What has therefore proven itself is several shorter sessions instead of one marathon day, virtual breaks, smaller groups, breakout rooms for the chaotic exploration and a prepared board with a legend and sample notes.
Let participants try out the tool briefly beforehand so that the first half hour is not spent on questions about how to use it. And for sensitive process information, check the hosting location and data processing terms of the chosen tool in advance.
From the workshop to bounded contexts and domain-driven design
For software architecture, the greatest value of event storming lies in the boundaries that become visible on the wall. Pivotal events, swimlanes and changes in the actors involved show where one sub-area ends and another begins. Places where the language changes are particularly revealing: if "order" in sales means the signed quote and in production the production order, a boundary probably runs there.
In DDD, such areas with their own unambiguous language are called bounded contexts. Martin Fowler describes the concept in his bliki entry "BoundedContext" as a central pattern of strategic design. The terms on the orange notes also form the basis for a shared business language, the ubiquitous language.
Aggregates, commands and events are then derived directly from the software design format. Events that cross context boundaries become candidates for integration events between modules or microservices. When replacing legacy software, the wall also shows which sub-areas can be extracted first. The prioritised hotspots move into the backlog or a discovery phase as risks and open questions.
Hypothetical example: event storming at a mechanical engineering company
The following example is entirely fictitious and serves only as an illustration. A mid-sized special machine builder plans to modernise its organically grown order processing. Before software is discussed, management invites sales, design, purchasing, production, service and IT to a big picture event storming. The timeline runs from "enquiry received" to "maintenance contract concluded".
Three pivotal events quickly crystallise: "order confirmed", "design released" and "machine accepted". Most of the pink hotspots gather between order confirmation and design release. Customer changes arrive there by email without anyone checking the effects on price and delivery date. It also turns out that sales and production mean different things by "order".
From the wall, the team derives three candidates for bounded contexts: quotes and sales, order processing and production, and service. In the subsequent process modelling for change management, a new policy emerges: "When a change request arrives after design release, trigger a cost and schedule check". For the service portal, the next step is a make-or-buy decision.
Typical mistakes in event storming
The method seems simple, but some mistakes come up again and again and significantly reduce the result:
- Wrong format for the question: anyone who introduces aggregates and policies in the big picture overwhelms business experts and loses the overview.
- Incomplete guest list: if only IT people are in the room, the result is a model based on assumptions.
- Too little space: a short wall or a small board limits thinking and creates artificial constraints.
- Activities instead of events: "create quote" is a command. Without consistent use of the past tense, cause and result become blurred.
- Debating hotspots immediately: long debates on principles drain the group's energy. Mark, park and clarify later.
- Facilitation with its own agenda: a facilitator who dictates content merely confirms their own view.
- No follow-up: without photos, owners and next steps, the result fizzles out.
- Mistaking the wall for a specification: event storming does not replace specifications, but it provides a robust basis for them.
Frequently asked questions about event storming
What distinguishes event storming from BPMN?
BPMN is a standardised notation that produces exact, often executable process models and is usually created by specialists at a computer. Event storming is a group format with a deliberately simple notation that puts shared understanding and open questions in the foreground. The two are not mutually exclusive: the results of an event storming can later be refined in BPMN.
How many people should take part?
That depends on the format. A big picture thrives on breadth and, according to the DDD Crew, can also work with more than 30 people, provided there is enough wall space and facilitation. Process modelling and software design work with smaller groups that work in depth on a specific process or sub-area.
Do I need domain-driven design for event storming?
No. Big picture and process modelling also work without knowledge of DDD, for example for process analysis or to prepare a software selection. Only in the software design format do DDD terms such as aggregate or bounded context help to translate the result into an architecture.
Does event storming also work remotely?
Yes, with online whiteboards such as Miro or Mural. Plan several shorter sessions with breaks, prepare the board with a legend and use breakout rooms so that everyone gets a say.