What this looks like in practice
The tools: Miro, a webcam, and a facilitator.
We use Miro (or Mural) as the shared wall. Each sticky-note color has a fixed meaning: orange for Domain Events, blue for Commands, yellow for Actors, purple for Policies, pink for Read Models, red for Hot Spots where the group is stuck or disagreeing. This color grammar is Alberto Brandolini's invention and is used worldwide; if you ever bring another consultant in, they will already speak it. Sessions run on Zoom or Teams with cameras on. We strongly prefer cameras on: Event Storming depends on reading the room, catching the raised eyebrow when someone hears a rule they didn't know existed. The facilitator (always one of us) is responsible for asking questions, not for knowing answers.
The agenda: two passes, escalating depth.
Session 1: Big Picture (2 hours). We start with a blank board and a single domain event the facilitator has prepared. Participants spend 20–25 minutes in "chaotic exploration," writing down every event they can think of, no order, no discussion. Then we sort the events into a chronological timeline together. This is where most of the disagreements surface. We end by marking Hot Spots (red stickies) on the places where the group couldn't agree or didn't know. Session 2: Process & Design Level (2 hours, usually a week later). We pick the two or three riskiest areas, usually the ones with the most Hot Spots or the ones tied to the business outcomes that matter most. We add Commands, Actors, Policies, Read Models, and External Systems around the events. By the end, we have enough structure to propose Aggregates, the units of consistency in the eventual code.
The participants: four to eight people, mixed.
The single biggest predictor of a good Event Storming outcome is who's in the room. We need at least two domain experts (people who actually do the work, not their managers), one or two technical leads from your side, a product owner, and our facilitator. Eight is the soft cap; above that, the board becomes unreadable and the quiet voices get drowned out. We interview every participant for 15 minutes before the first session. This matters more than it sounds: it lets us pre-seed three or four domain events we know will provoke disagreement, so we don't waste the first hour on throat-clearing.
Energy management is a real concern.
A remote Event Storming session cannot be longer than two hours. People's attention cratered after ninety minutes in person; it craters faster online. We break every 40 minutes for five minutes, on a timer, no exceptions. We end on time. If there is more to discover, we schedule another session. We do not push through. Between sessions, we send a short written recap (what we mapped, what we disagreed about, what Hot Spots remain) and homework: "please confirm with your team whether the Credit Check happens before or after Inventory Reservation." This is how a single disagreement turns into a resolved architectural decision.
What you walk away with
- Standard color grammar (orange/blue/yellow/purple/pink/red). Portable across consultants and tools.
- Two 2-hour sessions: Big Picture first, then Process & Design Level on the riskiest areas.
- 4–8 participants including at least two real domain experts, not just their managers.
- Pre-session interviews with every participant to pre-seed events that will provoke productive disagreement.
- Written recaps between sessions convert disagreements into resolved architectural decisions.
- Miro board is archived and handed over. It becomes living documentation, not a meeting artifact.