Event storming

Event Storming is a workshop-based technique for exploring complex business domains by modeling events, commands, and actors collaboratively. Created by Alberto Brandolini, the method uses sticky notes on a large surface to build a shared understanding of how a system or process actually works. It's intentionally low-tech and high-energy, designed to surface knowledge from across an organization quickly and engage everyone from domain experts to developers in productive conversation.

Why it matters

Complex systems are hard to understand because knowledge is distributed across many people, documentation is often outdated or incomplete, and assumptions go unexamined. Traditional requirements gathering-interviews, documentation reviews, meetings-tends to be slow, fragmented, and biased toward the perspectives of whoever happens to be in the room.

Event Storming addresses these problems through collaborative, visual exploration. By putting everyone in the same room with the same problem space visible on the wall, it surfaces disagreements, reveals hidden complexity, and builds shared understanding faster than sequential conversations ever could. The visual nature makes gaps and contradictions immediately apparent rather than buried in documents nobody reads.

For product teams, Event Storming provides rapid domain education and requirements discovery. Instead of weeks of interviews and documentation review, a few days of Event Storming can map out a complex domain well enough to begin meaningful work.

How event storming works

Core elements

Event Storming uses colored sticky notes to represent different concepts. While colors can vary, common conventions include:

Domain Events (orange) represent things that happen in the system-state changes that matter to the business. Events are written in past tense: "Order Placed," "Payment Received," "Shipment Delivered." They're the backbone of the model.

Commands (blue) represent user or system actions that cause events. A command triggers an event: "Place Order" (command) leads to "Order Placed" (event).

Actors (small yellow) represent who or what issues commands. This might be a user role, an external system, or a scheduled process.

Aggregates (large yellow) represent clusters of domain objects that are treated as a unit for data changes. In Domain-Driven Design terms, these are consistency boundaries.

Policies (purple/lilac) represent automated reactions-when one event triggers another action. "When Payment Received, then Ship Order" is a policy connecting events.

External Systems (pink) represent integrations or dependencies outside the bounded context being modeled.

Read Models (green) represent the data views that users need to make decisions or take actions.

Hot Spots (pink or red rotated) mark areas of confusion, disagreement, or questions that need resolution.

The workshop flow

#### Big Picture Exploration

The workshop typically begins with a chaotic phase where participants write domain events on orange sticky notes and place them on a timeline. No discussion, no ordering-just rapid generation of events that happen in the system. This surfaces knowledge quickly and engages everyone.

After initial brainstorming, the group works to order events chronologically, from left (earlier) to right (later). This ordering process sparks valuable conversations: "Wait, doesn't X happen before Y?" or "I didn't know Z was a separate step."

#### Enforcing the Timeline

Once events are roughly ordered, the group adds commands, actors, and policies. Each event gets connected to what triggers it and what follows from it. The timeline becomes a map of cause and effect through the system.

This phase often reveals disconnections-events with no obvious trigger, or commands with unclear outcomes. These gaps become discussion points and hot spots.

#### Identifying Aggregates and Bounded Contexts

For software modeling purposes, the events and commands get clustered into aggregates-groups of related concepts that change together. These clusters often correspond to bounded contexts, areas of the system with consistent terminology and clear boundaries.

This clustering informs system architecture: where to draw service boundaries, how to organize code, what teams might own what parts.

Workshop logistics

Event Storming requires space-literally. Participants need a large, empty wall or multiple whiteboards where a timeline can span many meters. Standing around a shared surface encourages engagement and makes the full picture visible to everyone.

Sessions typically run 3-8 hours, sometimes across multiple days for complex domains. Shorter sessions work for focused problem exploration; longer sessions tackle entire business domains.

Participants should include diverse perspectives: domain experts who know how the business works, developers who will build systems, product people who understand user needs, and stakeholders who care about outcomes. The collision of perspectives is what makes Event Storming valuable.

Applications

Domain discovery

The most common use: understanding a complex domain quickly. When a team inherits a legacy system, enters a new problem space, or needs to align on how something actually works, Event Storming accelerates learning dramatically.

Process improvement

By making the current state visible, Event Storming reveals inefficiencies, unnecessary complexity, and opportunities for improvement. The "future state" can be modeled by rearranging the timeline-removing events, adding new ones, or changing flows.

Software design

Event Storming maps naturally to event-driven architectures and Domain-Driven Design. The events become domain events in code; the aggregates become software aggregates; the bounded contexts inform service boundaries.

Requirements gathering

Instead of writing requirements documents, teams can use Event Storming to explore what needs to be built. User stories and specifications emerge from the collaborative modeling rather than preceding it.

Benefits and limitations

Benefits

Speed. Complex domains that would take weeks to understand through documentation and interviews can be mapped in days of Event Storming.

Engagement. The hands-on, visual nature engages participants who might zone out in traditional meetings. Domain experts often find Event Storming more natural than answering interview questions.

Shared understanding. Everyone sees the same picture, disagreements surface immediately, and the model represents genuine group knowledge rather than one person's interpretation.

Actionable output. The resulting model directly informs software design, process improvement, and product decisions. It's not documentation for its own sake.

Limitations

Facilitation skill required. Event Storming can go off the rails without skilled facilitation. Someone needs to keep energy high, manage conflicts, and guide the process through its phases.

Space requirements. You genuinely need a big wall or multiple surfaces. Virtual Event Storming is possible but loses much of the energy and visibility.

Participant fatigue. Multi-hour standing workshops are exhausting. Complex sessions need breaks and may need to span multiple days.

Not self-documenting. The sticky note model is ephemeral. Capturing the results in durable form requires additional effort-photography, digital transcription, or follow-up documentation.

Event storming for product teams

Product managers benefit from Event Storming in several ways:

Rapid domain education when joining a new product area or company. A few Event Storming sessions provide deeper understanding than weeks of documentation review.

Requirements discovery surfaces what needs to be built through collaborative exploration rather than isolated specification.

Stakeholder alignment happens naturally when diverse participants build a shared model. Disagreements become visible and resolvable rather than hidden and festering.

Technical communication improves when product managers understand the domain model that shapes technical decisions.

Klero complements Event Storming by providing customer feedback that grounds the modeling in real user experiences. When running Event Storming sessions, teams can reference actual customer complaints, feature requests, and usage patterns to ensure the model reflects how users actually interact with the system.