Running the Session

Step-by-Step Procedure

Phase 1 — Chaotic Exploration: Events First

Open the session by telling participants one rule: write domain events on orange sticky notes and place them on the wall. That is it. No sorting, no coordination, no raising hands to speak. The initial chaos is intentional.

The first substantive step in any Event Storming session is event discovery. All other notation elements — commands, aggregates, policies, actors — come later. Starting with events only establishes the temporal backbone of the model and gives every participant, regardless of technical depth, a way to contribute immediately.

Let the storm run until the pace of new stickies clearly slows. Resist the urge to organize too early. Productive noise is normal and valuable.

Decision point: If a participant wants to add a command or policy during this phase, note it on a different color and tell them it will be placed properly in the next phase. Do not stop momentum to explain notation.

Phase 2 — Timeline Ordering

Once the event torrent has ebbed, shift to making sense of what is on the wall.

Event Storming uses a horizontal timeline with an explicit left-to-right arrow of time as the organizing principle. Earlier events go to the left; later events go to the right. Ask participants to walk the wall and start arranging their events in the sequence they occur in the real domain.

This phase surfaces the first round of productive conflict: two participants who thought they agreed on a process will discover they have different mental models. That is not failure — that is the workshop working. Rather than resolving these disputes immediately, mark them with a red or pink "hotspot" sticky and move on. Hotspots are your inventory of things worth discussing, not blockers.

The timeline acts as both a modeling structure and a communication device. Any observer can immediately read process flow and identify where temporal relationships are missing or ambiguous. That legibility is part of what makes the artifact valuable beyond the room.

Decision point: If two events cannot be ordered (they genuinely happen in parallel or in either order), do not force a sequence. Allow them to sit at the same position on the timeline — this will matter when you introduce swimlanes.

Phase 3 — Adding Context: Commands, Actors, Policies

With a rough timeline in place, layer in the other notation elements. Work through the timeline left to right, adding:

• Commands (blue) that trigger each event
• Actors or personas (yellow) who issue those commands
• Policies or business rules (purple/lilac) that respond to one event and trigger the next

This is where facilitator expertise in both domain concepts and DDD principles becomes essential. Participants will name things differently, confuse commands with events, and struggle to articulate what triggers certain transitions. Your job is to ask questions — "What has to happen before this can occur?" or "Who decides to do that, and what are they responding to?" — not to answer them yourself.

Phase 4 — Problem Identification and Hotspot Review

Return to the hotspots. Work through each one as a group, not to achieve resolution, but to understand the nature of the disagreement.

Some hotspots reveal simple misunderstandings: two people used different words for the same thing. Others reveal genuine ambiguity in the domain — the business has never actually decided how this case works. Others reveal missing events or entire subdomains the group has not yet modeled.

Each type requires a different response:

Hotspot type	Response
Naming disagreement	Establish a canonical term on the wall; document alternatives
Undecided business rule	Escalate to domain owner; park for follow-up
Missing events	Open a new area of the wall for the missing subdomain
Hidden dependency	Draw an explicit link; note it as a potential coupling risk

Phase 5 — Swimlane Organization

Once the main timeline is coherent, look for events that are not really sequential — they occur in parallel or belong to clearly separate concerns.

Swimlanes visualize parallel processes and independent timelines. When you introduce horizontal lanes to separate concurrent sequences, the emerging boundaries frequently indicate potential bounded contexts in the eventual architecture. Each swimlane can represent an independent model or domain concern.

Introduce swimlanes by asking: "Does this sequence of events actually wait for that sequence, or can they happen independently?" Let the participants draw the boundaries themselves. Your role is to ask the questions that reveal the dependencies, not to impose a structure you have pre-decided.

Key Principles

The conversation is the output. The act of building models collaboratively is as important as the resulting artifact. The stickies are a residue of something more valuable: the shared understanding constructed in the room. Protect the conversation.

Facilitation is fifty percent technical, fifty percent human. Effective facilitation requires constant observation of group dynamics — listening to discussion velocity, noticing where productive conversation occurs, reading non-verbal cues to detect disengagement. You cannot manage a session from the front of the room with your back to the participants.

Chaos before order. Premature organization kills discovery. The chaotic phase is not inefficiency to be optimized away — it is the mechanism by which participants surface what they know without social filtering.

Hotspots defer, not avoid. Conflict is signal, not noise. Marking a hotspot means "this is worth returning to with the right people" — not "we disagree and cannot move forward."

Ownership comes from construction. Participant engagement and ownership are critical factors in workshop effectiveness. When participants build the model themselves, they understand and trust it. When conclusions are handed to them, they do not.

The facilitator holds the process, not the answers. Facilitation decisions — when to challenge, when to redirect, when to drill deeper versus move forward — require domain knowledge, interpersonal awareness, and contextual understanding. These are judgment calls that cannot be delegated.

Annotated Case Study

Reconstructing an Order Lifecycle in a Legacy Fulfillment System

A development team is preparing to modernize a decade-old fulfillment platform. The system has no architecture documentation. Three developers still understand parts of it. Two business operations leads have worked with it for eight years. A product manager joined six months ago.

The facilitator opens with the chaotic exploration phase. Within twenty minutes there are forty-three orange stickies on the wall. Several events appear in duplicate from different participants: "Order Submitted," "Order Placed," and "Order Received" — three stickies from three people describing what is, or is not, the same moment.

Why this matters: Legacy systems frequently have significant undocumented business workflows that exist only in operational code and the memory of long-tenured employees. The duplicate events are not sloppy writing — they are evidence that the same moment is understood differently by different parts of the organization.

The facilitator does not resolve the ambiguity by fiat. Instead, they place a hotspot on all three stickies and continue.

During timeline ordering, a sharp disagreement emerges: one developer says fraud screening happens before payment authorization; an operations lead insists it happens after. Both have been working with this system for years.

The facilitator's move: Ask each person to describe what they have directly observed, not what they believe the system should do. The developer pulls up a log snippet. The operations lead describes a customer complaint pattern. They are both right — fraud screening runs in parallel with payment authorization, with different paths depending on the risk score. This is a swimlane, not a sequence.

What surfaced: Event Storming workshops force teams to collaboratively articulate implicit workflows by building explicit event timelines that trace what happens, in what sequence, under what conditions, and with what consequences. The contradiction between the developer's and operations lead's mental models was not a mistake — it was a discovery. The system had two parallel paths that were never explicitly documented. Neither participant knew the other's path existed until this moment.

By the end of the session, the hotspot on "Order Submitted / Placed / Received" resolves into three distinct events with different triggers and audiences:

• Order Received — the system acknowledging the inbound request (technical)
• Order Validated — the system confirming the order is processable (domain rule)
• Order Confirmed — the business communicating commitment to the customer (business event)

These distinctions will later inform how the team draws bounded context boundaries between an ingest service, a validation service, and a customer communication service.

Common Misconceptions

"The facilitator should know the domain well enough to correct participants."

No. The facilitator's domain knowledge is for asking better questions, not for providing answers. If the facilitator starts correcting domain content, participants defer to them and stop surfacing what they know. The facilitator's authority is over the process, not the model.

"Disagreements slow the session down and should be resolved immediately."

Unresolved disagreements captured as hotspots are the most valuable output of the early phases. Forcing resolution by authority produces a model that reflects the loudest voice, not the actual domain. A skilled facilitator prevents dominant voices from biasing the model — which includes their own voice.

"Once we've done Event Storming, the model is the documentation."

The stickies are a starting point, not a conclusion. The conversations that occur during the workshop are where real learning happens. The wall is a record of that conversation, but shared understanding lives in the participants. It must be maintained through continued collaboration, not assumed to persist through an artifact.

"We can run this session in two hours if we stay focused."

Event Storming is an intense format requiring sustained attention. Facilitators must actively manage participant energy through environmental support and careful observation of behavioral indicators such as sticky note velocity and discussion intensity. Compressing time compresses discovery. A session that feels efficient because nothing difficult came up probably avoided the difficult things.

"The facilitator-participant separation doesn't apply when a technical lead facilitates their own team."

This is the hardest misconception to counter because it feels pragmatic. When you know the domain and the people, the pull to participate is constant. But the facilitator must maintain momentum, ensure balanced participation, and prevent dominant voices from biasing the model — which is structurally impossible if you are also one of the dominant voices contributing content. If you must do both, build in explicit role-switching moments and make them visible to the room.

Active Exercise

Facilitation Pressure Test

This exercise simulates the judgment demands of live facilitation. Work through each scenario and decide: what do you do, and why?

Scenario A — The silent expert

Your most experienced domain person has been quiet for forty minutes. They have placed two stickies while everyone else has placed fifteen or more. What do you do?

Consider: Is silence disengagement, or is this person processing? How do you check without embarrassing them publicly? What questions could you ask that invite rather than pressure?

Scenario B — The technical rabbit hole

Two developers have moved into a detailed debate about whether a particular event requires an eventual consistency model or a synchronous call. The rest of the room has disengaged. This conversation is technically important but off-topic for the current phase.

Consider: How do you interrupt without dismissing the concern? Where does this conversation belong, and how do you park it with enough structure that it actually gets resolved later?

Scenario C — The contested hotspot

A hotspot has been on the wall for ninety minutes and the group keeps returning to it. Every time someone raises it, the conversation restarts rather than progresses. The same two people are disagreeing and neither is updating their position.

Consider: What kind of disagreement is this? (Naming? Undecided business rule? Genuine ambiguity?) What decision-making process would move it forward? Who in the room has the authority to close it?

Scenario D — The knowledge holder who just left

You are forty-five minutes into the session and the one person who understands the payment processing path has been pulled into an incident response. You have seventeen unplaced stickies in that part of the domain.

Consider: Do you stop, continue, or restructure? What can the group productively do in that section without the expert? How do you capture what is known versus what is uncertain?

After working through each scenario, compare your decisions with a colleague who also completed the exercise. Focus on where your reasoning diverged, not just your conclusions.