Event Storming
Rapidly model complex domains with the full team
Event Storming is a collaborative workshop technique where a diverse group (developers, domain experts, PMs, and ops) map a business domain by placing domain events (things that happen) on a timeline. It rapidly surfaces complexity, gaps in understanding, bottlenecks, and bounded contexts. Originally designed for software modelling, it is also used for product discovery, process redesign, and cross-team alignment.
Developed by Alberto Brandolini around 2012. Documented in the book 'Introducing EventStorming' (2021). Grew from Domain-Driven Design practice and became popular in microservices architecture and product discovery contexts.
Use Event Storming when
- ✓Designing or redesigning complex business domains for a new system or major refactor
- ✓Aligning product, engineering, and business stakeholders on how a domain actually works
- ✓Microservices architecture workshops where team boundaries need to reflect domain boundaries
- ✓Discovery for products in complex domains (finance, logistics, healthcare) where the business rules are unclear
Avoid it when
- ✗Simple, well-understood domains where the complexity doesn't justify a full-day workshop
- ✗Teams without genuine domain experts available to participate — you need people who know the business, not just the system
- ✗Feature-level planning for known workflows — Event Storming operates at domain and process level
Key Concepts
Something that has happened in the domain that is relevant to the business. Written in past tense on orange sticky notes. E.g. "Order Placed", "Payment Failed".
An action that triggers a domain event. Written on blue sticky notes. "Place Order" causes "Order Placed".
A business rule triggered by an event. "Whenever X happens, do Y." Written on purple sticky notes.
A cluster of related events and commands that form a consistent unit of business logic. Maps to a potential microservice or module.
A boundary within which a particular model applies. Different parts of the organisation may use the same word ('order') to mean different things.
A sticky note placed on the timeline to flag an area of confusion, conflict, or missing knowledge that needs follow-up.
How it works
All participants add domain events to the timeline simultaneously. No rules, no judgment. Get all events on the board.
Facilitate ordering of events. Surface conflicts and duplicates. Identify hot spots.
For each event, identify the command that triggered it and any policies it activates.
Cluster related events into aggregates. Draw bounded context lines. These become team and service boundaries.
Tools that support Event Storming
Industry standard for software development teams — most PMs will encounter Jira in their career
Exceptionally intuitive and visually clean interface — one of the lowest onboarding friction tools for non-technical teams
Highly visual and intuitive interface with color-coded boards — one of the easiest PM tools for non-technical teams to adopt
All-in-one platform replacing multiple tools — docs, whiteboards, goals, time tracking, chat, and project management in a single workspace
Unmatched flexibility as an all-in-one workspace — combines docs, wikis, databases, and project management in a single tool
Spreadsheet-familiar interface makes adoption easy for teams transitioning from Excel — minimal training needed for basic use
Extremely intuitive drag-and-drop Kanban interface — virtually zero learning curve, new users productive within minutes
Browser-based with no installation required — runs on any OS and enables instant sharing via URL, removing friction for cross-functional collaboration with PMs, engineers, and stakeholders
Frequently Asked Questions
Big Picture Event Storming (full domain) takes 4–8 hours. Process Modelling (a specific process) takes 2–4 hours. Design-Level Event Storming (software design) takes 4–8 hours per bounded context. Plan for a full day for any non-trivial domain.
An experienced facilitator significantly improves the outcome, especially for the first session. The facilitator manages energy (sessions are intense), surfaces hot spots, and guides the transition from exploration to modelling. Alberto Brandolini and his team offer training for facilitators.
Photograph and digitise the board. Identify the top hot spots and assign owners to resolve them. If it was a design-level session, translate the output into domain model code. If it was a discovery session, feed insights into the product backlog and opportunity solution tree.