Event Storming Guide

Event storming is a workshop technique where people from across a business stick orange notes on a long wall to map what happens, in order. Because it uses plain language and sticky notes, product owners, developers and operations staff can contribute equally. The result is a shared picture and a set of boundaries to design around.

Learning goals

Facilitate a big picture event storming session
Recognise the main sticky note types and their meaning
Find hotspots, conflicts and missing knowledge
Derive candidate bounded contexts from the timeline

Step-by-step procedure

Prepare a wall at least six metres long, a stack of sticky notes in several colours, markers and a room with space to stand. Invite people who know the process end to end.
Explain the one rule: write domain events in past tense, such as Order Placed or Payment Declined, one per note, in orange.
Let everyone add events in parallel without discussion for fifteen minutes. Expect duplicates and gaps.
Arrange events into a rough timeline from left to right. Merge duplicates and mark disagreements with a purple hotspot note.
Add the commands that trigger events in blue, the actors who issue them in yellow, and external systems in pink.
Add policies, the rules of the form whenever this event happens, then do that, in lilac.
Look for natural clusters where vocabulary changes or ownership shifts. Draw vertical lines to mark candidate boundaries.
Photograph the wall, list the hotspots as follow up questions, and assign people to resolve them.

Worked example

During an online retail session, the group places Order Placed, Payment Authorised, Stock Reserved, Parcel Packed and Parcel Delivered along the wall. Two people disagree about when stock is reserved, and a hotspot is added. The word Customer turns out to mean a paying account in billing but a delivery recipient in fulfilment, a sign of two different contexts. A policy appears: whenever Payment Authorised, then reserve stock. The facilitator draws boundaries around ordering, billing, inventory and shipping. The follow up list includes who owns refunds, and how long reservations last. The team now has a map for splitting work and a list of questions that would otherwise have surfaced during implementation.

Exercises and templates

Event storm a process you know, such as onboarding a new user, in sixty minutes.
Find a word that means different things in two parts of your business.
Turn three hotspots into questions and assign an owner to each.

Template:

Orange: domain event
Blue: command
Yellow: actor
Pink: external system
Lilac: policy
Purple: hotspot or question

Common pitfalls

Letting one expert dominate. Ask quieter participants to place notes first.
Jumping to technical design before the language is understood.
Cleaning up the wall too early and losing the evidence of disagreement.
Treating the boundaries as final. They are hypotheses to test with the first implementation slice.

Follow-up and continuous improvement

Within a week, convert the wall into a digital diagram and share it with everyone who attended. Pick one boundary and slice a thin end to end flow across it as the first piece of work. Revisit the wall after the first release, since real implementation will confirm some boundaries and challenge others.

Adapting this to your team

Treat everything above as a starting point rather than a rulebook. Smaller teams can compress the sessions and merge roles, while larger organizations may need written templates, a shared calendar and a named owner for the practice. Begin with one pilot on a real project, collect honest feedback from participants, and adjust the format before you roll it out more widely. Consistency matters more than perfection, so favour a simple routine you will actually repeat.

Key takeaways

Events in past tense keep the conversation about facts
Parallel brainstorming surfaces knowledge quickly
Disagreement on the wall is valuable information
Boundaries follow language and ownership, not technology