Event Storming template:
the notation, the wall, and how to set it up.

The notation: seven stickies

Colours vary between teams. Keep them consistent within a session and put the legend on the board.

Three levels, three different sessions.

Event Storming is not one workshop. Alberto Brandolini, who created the method, describes three levels, and running the wrong one wastes a day.

Big Picture is the whole business, cross-department, usually chaotic on purpose. Process Modelling narrows to one flow and adds commands, actors, and policies. Software Design goes down to aggregates and is where the model starts to look like code.

For legacy modernization we almost always start at Big Picture, because the thing we need first is the parts of the business nobody wrote down. The narrower levels come later, once we know which process is worth rebuilding.

How the wall is laid out.

The wall is a timeline. Left is earlier, right is later, and that is the only rule that cannot bend.

Everything else is scaffolding around it: a wide band across the middle for the event flow, vertical dividers at the pivotal events where the business genuinely changes phase, a parking lot at the bottom for anything off-topic, and a hotspot column so unresolved arguments have somewhere to live.

1. A long horizontal band, and nothing else at first
   Give yourself far more width than feels sensible. Sessions run out of wall long before they run out of events, and rearranging a cramped timeline eats the afternoon.
2. Pivotal events as vertical dividers
   Once the timeline settles, find the handful of events where the business state fundamentally changes: order confirmed, contract signed, shipment dispatched. Mark them with full-height lines. They become the natural boundaries between contexts later.
3. Swimlanes only after the flow is agreed
   Splitting into lanes by department or system too early makes people model their org chart instead of the business. Add lanes once the events are stable, if at all.
4. A parking lot and a hotspot column
   Both need to be visible, not tucked away. Their job is to let you move on without losing what was raised.

Setting it up in Miro in five minutes.

Nothing here is Miro-specific beyond the menu names. Mural, FigJam, and a physical wall all work, and the physical wall is still better if you can get everyone in one room.

1. Make the frame far too big
   Start with a frame around 10,000 by 4,000 pixels. It will look absurd and then it will fill up.
2. Set the eight sticky colours as your custom palette
   Use the hex values in the legend above. Doing this once at the start stops the colours drifting mid-session, which quietly destroys the meaning of the wall.
3. Paste the legend into the top-left corner
   Every participant will forget what lilac means at least twice. A visible legend saves you from answering it twenty times.
4. Draw the timeline arrow across the middle
   One long arrow, left to right. It is the single most useful piece of furniture on the board.
5. Add a parking lot and a hotspot zone below
   Two labelled rectangles are enough.
6. Lock everything except the stickies
   Frames, arrow, and labels locked. Otherwise someone drags the timeline into the parking lot within the first ten minutes.

The rules that decide whether it works.

The notation is easy. Facilitation is what separates a wall full of insight from a wall full of nouns.

These are the rules we hold to, and the reasons they exist.

1. Everyone writes at the same time, in silence, first
   Chaotic exploration before discussion. If you open with a conversation, the loudest person's mental model becomes the wall.
2. Past tense, always
   “Order placed”, not “place order” or “ordering”. Tense discipline is what keeps events distinguishable from commands, and it is worth correcting every single time.
3. Do not resolve hotspots in the room
   Capture and move on. A single unresolved rule can absorb an hour and the answer usually lives with someone who is not present.
4. Duplicates are signal, not noise
   The same event written by four people in four places tells you it matters and that the vocabulary is inconsistent. Leave them up until the enforced narrative.
5. Walk the timeline out loud at the end
   One person narrates the flow start to finish while everyone listens. Gaps and contradictions surface in minutes, and this is where the real disagreements finally appear.

Five ways it goes wrong.

Every one of these we have either done ourselves or walked into.

1. Starting with commands or aggregates
   Both feel more like software and both anchor the group in the current implementation. Events first, for at least the first hour.
2. Modelling the system instead of the business
   If the wall reads “record written to table”, you are describing the legacy application rather than the work it supports. The test: would a domain expert with no technical background recognise this?
3. Only inviting engineers
   The value is in the people who know the exceptions. If nobody in the room has processed a refund by hand, the wall will be tidy and wrong.
4. Stopping when the wall looks neat
   A tidy wall early usually means the hard parts have not surfaced yet. Messy is a good sign at the halfway mark.
5. Treating the output as documentation
   The board is a byproduct. The shared understanding is the deliverable, which is why remote sessions need extra effort to keep everyone genuinely present.

Common questions

Do I need Miro specifically?

No. The notation and layout work on any whiteboard tool, and on an actual wall with actual sticky notes. We use Miro for distributed sessions because unlimited canvas and locked frames help, but a physical wall with everyone in one room still produces better conversations when it is an option.

What are the standard Event Storming colours?

Orange for domain events, blue for commands, lilac for policies, pink for external systems, large yellow for aggregates, small yellow for actors, green for read models, and red for hotspots. Teams do vary this, and that is fine as long as it stays consistent within a session and the legend is on the board.

How long does a session take?

A Big Picture session on a single legacy application typically runs a half day to a full day. Going deeper into Process Modelling for one flow is usually another day. We would rather run two focused sessions than one exhausting one, because quality of attention drops sharply after about four hours.

How many people should be in the room?

Enough to cover the process end to end, which usually means six to twelve. Below six you tend to miss whole branches of the business. Above twelve, people stop contributing and start watching.

What do we do with the board afterwards?

The wall itself ages quickly. What lasts is the list of pivotal events, the hotspots with owners assigned, and the boundaries you discovered. Those feed directly into deciding what to modernize first and where the seams are if you are sequencing a strangler fig migration.

Can you facilitate a session for us?

Yes, that is part of how we start modernization engagements. But the template above is genuinely everything you need to run one yourself, and plenty of teams should. If you get stuck partway, that conversation is usually more productive than starting from scratch with a facilitator anyway.

Related

Why Event Storming works · How we run it · Rewrite vs strangler fig