SHORT ANSWER
Event Storming is a workshop where business experts and engineers map a process as a timeline of domain events on sticky notes. Alberto Brandolini created it. It runs at three levels: Big Picture (whole business, 1 to 2 days), Process Level (one flow, half a day to a day) and Design Level (the software model). You leave with a shared process map, a list of hotspots and candidate bounded contexts.
Event Storming is a workshop for exploring a business domain by placing domain events, things that happened and matter to the business, on a timeline of sticky notes. Alberto Brandolini created it, and teams use it widely with domain-driven design. In a few hours to two days, business experts and engineers build a shared map of how a process really works, where it breaks and how the software should be split. This guide covers the three levels, the colour legend, a worked example and how to run a session.
Why do teams use Event Storming?
Shared understanding, fast. Knowledge that normally sits in many separate interviews lands on one wall in one session.
Problems become visible. Disagreements, manual workarounds and unknowns get marked as hotspots instead of turning up months into a project.
Better software boundaries. Clusters of events point to bounded contexts, which become services, modules or team ownership lines.
Less requirements risk. A one or two day workshop with a short follow-up can replace much of the document-based analysis teams would otherwise do.
What are the three levels of Event Storming?
Level | Question it answers | Scope | Typical duration | Main output |
|---|---|---|---|---|
Big Picture | How does the whole business or value stream work? | Several departments, end to end | 1 to 2 days | Timeline of events, hotspots, pivotal events, candidate bounded contexts |
Process Level | How does this one process work, step by step? | One flow, for example order fulfilment | Half a day to 1 day | Events, commands, actors, policies, read models and systems in sequence |
Design Level | How should the software model this? | One bounded context | Several 2 to 4 hour sessions | Aggregates, business rules and a model developers can build |
Most organisations start with a Big Picture session to find where the real problems are. They then run Process and Design Level sessions only on the parts they’ll build or change.
What do the sticky-note colours mean?
Colours vary a little between facilitators, but the legend below is the most common. Put a printed legend on the wall so everyone uses the same grammar.
Colour | Element | What it means | Example |
|---|---|---|---|
Orange | Domain event | Something that happened, written in the past tense | Order placed |
Blue | Command | An intention or action that triggers an event | Place order |
Small yellow | Actor | The person or role issuing a command | Customer |
Lilac or purple | Policy | A reaction rule: whenever X happens, do Y | When payment is confirmed, reserve stock |
Green | Read model | Information someone needs to make a decision | Available delivery slots |
Large pink | External system | A system outside the scope of the model | Payment provider |
Large yellow | Aggregate | The object that enforces business rules (Design Level) | Order |
Red or hot pink | Hotspot | A problem, question, risk or disagreement | Who approves discounts over 20%? |
Event Storming example: order to delivery
Picture a consumer goods company that sells through a web shop and ships from two warehouses. In a Big Picture session, participants first write events on their own for about 20 minutes, then place them on the timeline:
Order placed
Payment authorised
Stock reserved
Order sent to warehouse
Order picked and packed
Shipment handed to carrier
Order delivered
Invoice issued
When the group walks the timeline, hotspots appear. Stock sometimes gets reserved in the wrong warehouse, customer service can’t see carrier status, and someone creates invoices for split shipments by hand. At Process Level, the group adds the command Reserve stock, a policy that says whenever payment is authorised, reserve stock in the nearest warehouse, and a read model showing stock per warehouse.
The model now shows three likely bounded contexts: Ordering, Fulfilment and Billing. Each has a clear owner and a clear set of events passed between them.
What we see when we run it on real projects
We used a Big Picture session while building a data and analytics portal for a global chemical and consumer goods company. The next phase covered requesting data access and creating new data products, and those processes depended on several services and teams. Nobody held the full picture.
One Event Storming session gave both teams a shared model of the process, deepened our understanding of the requirements and cleared up misunderstandings before we built anything. We then connected the portal to several data services and added notifications for requesters and approvers at each stage of a data request. The lesson: when a process crosses several services, map it on a wall before you design the APIs.
How do you run an Event Storming session?
Set the scope and invite the right people. Agree on where the process starts and ends, and invite 6 to 15 people who mix domain experts and engineers.
Prepare the space. Use 6 to 10 metres of paper roll on a wall, plenty of sticky notes in each colour, and no chairs around a table.
Explore freely. Everyone writes orange events in silence and places them roughly in time order.
Enforce the timeline. Remove duplicates, sort events and mark pivotal events that split the flow into phases.
Walk the story. Narrate the timeline from start to end, then from end to start, adding hotspots wherever someone hesitates.
Add people and systems. Place actors and external systems to show who and what is involved.
Prioritise problems. Use dot voting to pick the two or three hotspots worth solving first.
Capture and follow up. Photograph the wall or export the board, and agree on the next Process or Design Level session.
Remote vs. in-person Event Storming
Aspect | In person | Remote |
|---|---|---|
Energy and discussion | Highest, people move and talk in groups | Lower, needs more structure |
Session length | Full days are realistic | Blocks of 2 to 3 hours work better |
Tools | Paper roll and sticky notes | Miro, Mural or a similar digital whiteboard |
Preparation | Room, materials, travel | Board template, legend, tool practice |
Output | Photos, then transcription | Digital board ready to share |
Both formats work. In person suits a first Big Picture workshop with many departments. Remote suits distributed teams and follow-up Design Level work. Many teams mix the two, with an in-person kickoff and remote follow-ups.
How does Event Storming feed domain-driven design?
Event Storming is often the first practical step in domain-driven design. Clusters of events with shared language become bounded contexts. The words on the sticky notes become the ubiquitous language. Design Level sessions identify aggregates and the rules they protect.
Domain events on the wall often map straight to events in an event-driven architecture, so the step from workshop to backlog is short. Once the domain is clear, many teams scope the product next with a Lean Inception.
Common mistakes
Inviting only engineers, so the model reflects the current system rather than the business.
Jumping to commands and aggregates before the group agrees on the event timeline.
Letting one senior person dictate the order of events.
Leaving without prioritised hotspots or a named owner for next steps.
How RUBICON helps with Event Storming
We run Event Storming, Lean Inception and Design Sprint workshops as part of product discovery and architecture work. Our facilitators combine workshop experience with solution architecture, so the wall of sticky notes turns into a backlog and a system design without a handover gap. Since 2013 we’ve launched 60+ products for clients across Europe and North America, working from Sarajevo in the CET time zone.
See our Event Storming workshop and the full list of workshops. If a process keeps tripping up your teams, we can plan a session with you.
Frequently asked questions
What is Event Storming in simple terms?
Event Storming is a workshop where the people who know a business process and the people who will build software for it write down everything that happens as short past-tense events on orange sticky notes. They then arrange the notes on a long timeline. Gaps, disagreements and open questions show up quickly, so the group ends with a shared picture of how the business really works.
How long does an Event Storming workshop take?
A Big Picture session usually takes one to two days for a whole value stream. A Process Level session on a single flow takes half a day to a full day. Teams often run Design Level sessions in several two to four hour blocks alongside development. Remote sessions work best split into blocks of two to three hours over several days.
Who should attend an Event Storming session?
Invite 6 to 15 people: domain experts who do the work every day, product owners, engineers and architects, and ideally someone from operations, support or finance for flows that cross departments. A neutral facilitator keeps the session moving. The key rule is to have both the people with questions and the people with answers in the room.
What is the difference between Event Storming and process mapping?
Classic process mapping often starts from an agreed model and draws boxes and arrows. Event Storming starts from what happens, as events, and lets the model emerge from many participants at once. It's faster, it surfaces conflicts and unknowns as hotspots, and at Design Level it connects directly to software concepts such as commands, aggregates and bounded contexts.
More resources
