Event Storming is a workshop where people who know the business and people who build the product place the events that occur in a process, written on sticky notes, on a shared timeline. After the session you are left with a map that shows what happens in what order, who is responsible for what, and where the team disagrees. The method makes sense before a new module, when taking over a product from another team, and when departments argue about scope.
What is Event Storming?
The method was described by Alberto Brandolini in a text of 18 November 2013 as a workshop format for quickly learning about complex business domains. The basic unit is the domain event: a fact that matters to the business, written in the past tense: “Order was paid”, “Parcel was dispatched”.
Event Storming grew out of the Domain-Driven Design (DDD) community, an approach in which the structure of the software mirrors the language and divisions of the business. Brandolini pointed out that the model from the workshop makes it possible to quickly set the boundaries of contexts and aggregates. You do not need to know DDD to work on a product, however: an event map is as readable to a salesperson as it is to a developer.
The goal is not a complete model. The author of the method recommends accepting incompleteness, because the workshop exists to learn as much as possible in the shortest time.
When does Event Storming help in product development?
Problems surface earlier
Discrepancies that show up in documentation after weeks are visible on the wall straight away: two departments describe the same event differently, or nobody can say what happens between payment and dispatch. A change on a sticky note costs a minute; the same change after implementation takes developer work and testing.
Knowledge stops living in individual heads
People who usually talk through tickets work in one room: customer service, operations, product, developers. Everyone adds notes independently, so the voice of someone from the warehouse carries as much weight as the voice of a director. What these people know about customers is useful later when writing up personas and proto-personas.
Scope rests on the process, not on a wish list
When the whole process is on the wall, the decision about what goes into the first version concerns specific events, not slogans. It is a good starting point for setting the MVP scope and for drawing up user flows later.
What are the Event Storming levels and the full notation?
The method has three levels of detail, described among others in the glossary of the DDD Crew community:
- Big Picture. A picture of the whole business area. It is used to assess how an organisation works or whether an idea for a new product holds up. Even 10 to 30 people can take part.
- Process Modelling. One process described in detail: who makes a decision, based on what information, and which rule works automatically. It helps find bottlenecks.
- Software Design. A model from which the development team derives the structure of an event-based system.
On the lower levels further elements are added, each with its own colour:
| Element | Sticky note colour | What it means |
|---|---|---|
| Domain event | Orange | A fact that matters to the business, in the past tense |
| Command | Blue | A decision or action that triggers an event |
| Actor | Yellow, small note | A person, team or department executing the command |
| Aggregate or constraint | Yellow, large note | A business rule that must be met for the command |
| Policy | Lilac | A reaction: “whenever X happens, we do Y” |
| External system | Pink | An IT system the process uses |
| Read model | Green, small note | Information the actor needs to make a decision |
| Hot spot | Bright pink | A conflict, question or problem to be clarified |
In product workshops and UX workshops, where half the room is not technical, we use a simplified notation at Squares. We describe it below and mark where it departs from the original, so that people who know the method do not take the differences for a mistake.
How to run Event Storming step by step
Step 1: preparation
- Place. A long wall or several metres of paper, so that everyone can stand at the map at once. In the remote version, an online board such as Miro or FigJam plays this role.
- Materials. Sticky notes in several colours, a marker for each participant and a colour legend visible throughout.
- Participants. People who know the answers and people who know how to ask questions. In his first description of the method, Brandolini gave 6 to 8 people. Without someone from operations or customer service there will be gaps that nobody in the room notices.
Step 2: goal and scope of the session
The facilitator starts with one sentence about which process is being mapped and what the outcome should be, for example “redesigning the purchase journey” or “the scope of the first version of the application”. Without this, the map grows in directions nobody needs.
Step 3: events on the timeline
Participants write events on orange sticky notes, one event per note, in the past tense, and arrange them chronologically. For an online shop:
- Customer added a product to the basket
- Shop confirmed product availability
- Customer paid for the order
- Warehouse employee packed the product
- Courier collected the parcel
- Parcel reached the buyer
Notes can be moved and corrected throughout the workshop. A dispute over the order of two events is information, not a disruption.
Step 4: roles, stages and contentious points in the simplified notation
Once the events are arranged, we add further layers. This is our variant for a product workshop:
- Blue: roles. Who takes part in the process: the buyer, a shop employee, the courier. In Brandolini’s notation blue means a command, and actors are written on small yellow notes.
- Yellow: stages. Names of the process phases under which we group events: selection, order, payment, dispatch, delivery. In the original, yellow means an aggregate.
- Pink: hot spots. Places where the process is sensitive to errors or participants disagree. In the shop these will be availability checks (what happens when the system shows an incorrect status) and a failed payment.
- Green: opportunities. Ideas for improvement, for example parcel tracking or recommending similar products.
- White: parked topics. Questions and ideas outside the scope of the session, written down so that they do not block the work.
- Red: problems. Optional: what does not work today, for example a long customer service response time or recurring payment errors.
We add commands, policies and external systems when the map is to be used by the development team to design a module.
Step 5: conclusions and decisions
The session ends with a walk through the whole map from beginning to end and a write-up of three things: which hot spots must be resolved before work starts, which opportunities go into scope, and who is responsible for each open topic.
Event Storming from the end: when to start from the outcome?
At Squares we often run the session backwards. Instead of starting from the first event, the team starts from the end state, for example “Parcel reached the buyer” or “Patient received the test result”, and works back, each time answering the question of what had to happen immediately before.
This variant works when participants agree on the goal but differ in how they describe the way to it, and when the process has many possible starting points. Working from the end also cuts out events that do not lead to the outcome, so the map is shorter and it is easier to derive scope from it. In our experience it gives better results than arranging events from the beginning, especially in teams doing it for the first time.
How to run Event Storming remotely
The rules are the same; the rhythm changes. On an online board everyone writes in parallel, so the first phase is shorter, but it is harder to notice that someone has stopped participating. Three things help: a ready colour legend and timeline prepared before the session, shorter blocks with breaks instead of one long meeting, and a second facilitator who tidies the board while the first moderates the discussion.
What happens to the map after the workshop?
The map itself is not the outcome. Events turn into backlog items, hot spots into a list of decisions to make, and process stages into a split into releases. On this basis the scope of the first version is set, for which MoSCoW prioritisation is useful, and a development quote is prepared that is based on the process rather than on estimates from a conversation. The next steps are described in the post on what the software implementation process looks like.
Event Storming as part of a product workshop
At Squares, Event Storming is one of the techniques of the Product workshop, which lasts 1-2 weeks and ends with a document containing scope, decisions and the next step. In the Daily Effect application project, the conclusions from the workshops and event storming were translated into requirements and the scope of the first version of the product. The workshop has a fixed price set before work begins. When the question concerns the solution itself rather than the process, a design sprint is sometimes the better format.
Frequently asked questions
How many people should take part in Event Storming?
The author of the method, Alberto Brandolini, gave 6 to 8 people in his first description from 2013: those who know the answers and those who know how to ask questions. Big Picture sessions, covering the whole business area, bring together as many as 10 to 30 participants. The mix matters more than the number: business, operations and the technical team together.
How long does Event Storming take?
The time depends on the level and scope: mapping one process takes less time than a picture of the whole business area. At Squares, Event Storming is part of the Product workshop, which lasts 1-2 weeks including gathering context before the sessions and writing up conclusions after them. The sessions with the team themselves take part of that period.
Can Event Storming be run remotely?
Yes. The wall and sticky notes are replaced by an online board such as Miro or FigJam. The remote version needs more preparation: a colour legend and timeline ready before the session, shorter blocks with breaks, and a second facilitator who tidies the board. The advantage is that the map exists in digital form straight away and does not have to be copied out.
How does Event Storming differ from a customer journey map?
A customer journey map shows the process through one person’s eyes: their steps, emotions and touchpoints with the company. Event Storming shows everything that happens in the process, including what the customer does not see: employee decisions, automatic rules and systems in the background. The first technique serves experience design, the second setting the scope and logic of the product.
Do you need to know Domain-Driven Design for Event Storming?
No. The method comes from the DDD community and at the Software Design level leads to concepts such as aggregate and context, but the Big Picture and Process Modelling levels rely on events written in plain language. A participant needs to know their part of the process, not the notation. The facilitator explains the colour legend at the start of the session.
