Event Storming for Discovery, Drawing the Business on a Wall

TL;DR — Event storming is sticky notes, a long wall, and a clear question / it surfaces domain knowledge faster than any other workshop format I’ve tried / works for both greenfield discovery and reverse-engineering a legacy system.

The first time I ran an event storming session, I had no idea what I was doing. I’d read Alberto Brandolini’s notes, watched a couple of recordings, and decided to try it on a particularly tangled project — a financial reconciliation system where every conversation produced three new diagrams and zero agreement. Two hours in, the team had mapped out a process that we’d been arguing about for three months. The diagram wasn’t pretty. It didn’t matter. The argument was over.

That was about five years ago. I’ve run dozens of event storming sessions since, in various flavors and contexts, and it’s become my default move when a domain is complex enough that no single person in the room understands it end-to-end.

This post is a practical guide to running one. It’s the seventh post in my December leadership series, picking up the discovery thread from earlier posts on consultative discovery and discovery questionnaires. Where those were about one-on-one conversations, event storming is a group format — and it scales the discovery conversation in a way that nothing else I’ve tried does.

What Event Storming Is, Briefly

Event storming is a workshop format invented by Alberto Brandolini, anchored in Domain-Driven Design but useful well beyond it. The core idea: you put a long stretch of paper or whiteboard on a wall, give everyone sticky notes, and have them map the business as a sequence of events — past-tense things that happen — in time order.

The first version of the workshop has just one rule: orange stickies for events, written in past tense, placed on the wall in roughly chronological order. That’s it. From this minimal starting point, more advanced versions add commands (what triggers events), actors (who triggers them), policies (rules), read models (what people see), and external systems. But the simple version — just events, in time order — is where most of the value is.

The format works because it does three things at once:

• Forces concreteness. “We process invoices” becomes “InvoiceReceived, InvoiceValidated, InvoiceMatched, InvoicePaid.” Each event is a concrete moment in time, which is much easier to discuss than an abstraction.
• Surfaces hidden complexity. Stakeholders who would never have written it in a doc will pin a sticky for “InvoiceFlaggedForFraud” or “DuplicateInvoiceDetected” — the edge cases that always seem obvious in retrospect.
• Builds shared mental models. When everyone’s looking at the same wall, disagreements become visible. You can literally point at the sticky two people are arguing about.

Brandolini’s event storming book is the canonical reference. The Leanpub version is a long-running work-in-progress; even the early chapters are worth reading.

Running Your First Session

Here’s the format I run for a first session, calibrated for a small team (4-8 people) working on a moderately complex domain.

Preparation (1-2 hours)

Decide on the scope. “Map the order fulfillment flow from cart to delivery” is good. “Map our business” is too broad. Scope should fit on a wall and be processable in a single session.

Get the materials. You need a lot of orange sticky notes (Post-it 654, the small square ones, are fine), markers, and a long wall — ideally 4-6 meters of horizontal space, paper-covered if the wall isn’t whiteboard. For remote sessions, Miro or Mural with an event storming template works adequately. In-person is much better for first sessions because the physical movement around the wall is part of the practice.

Invite the right people. You want domain experts (the ones who actually do the work), engineers (who’ll build whatever you decide), and at least one product or business stakeholder. Avoid filling the room with engineers — the value of event storming comes from the non-engineers in the room writing stickies in their own language.

The Session (90 minutes minimum, 3 hours is typical)

Phase 1: Chaotic exploration (20-30 minutes). Everyone gets a stack of orange stickies and a marker. The prompt: “Write down events that happen in this domain, past tense, one per sticky. Stick them on the wall in roughly the right order. Don’t try to be complete. Don’t worry about overlaps. Just keep writing.”

This phase is supposed to be messy. People will write redundant stickies. They’ll disagree on order. That’s fine — the disagreements are the signal. Resist the urge to organize. Let the wall fill up.

Phase 2: Enforcing the timeline (30-45 minutes). Now the group walks the wall together, left to right, and discusses each cluster of stickies. The job is to:

• Merge duplicates
• Order events chronologically
• Identify gaps (events that should be there but aren’t)
• Mark hot spots — areas of disagreement, complexity, or unclarity — with a pink sticky and a short note

This is where the real discovery happens. The phrase you want to hear from a domain expert is “wait, that doesn’t actually happen first” or “you’re missing the part where…” Every such moment is information you didn’t have before.

Phase 3: Pivotal events and boundaries (20-30 minutes). Once the timeline is roughly settled, look for events that are pivotal — events where the business meaningfully changes state, where a different team gets involved, where a service boundary plausibly lives. Mark them. These are candidate seams for bounded contexts, microservices, or product boundaries, depending on what you’re using the session for.

Phase 4: Document and capture (15 minutes). Photograph the wall. Walk through it one more time, narrating. Identify follow-ups — questions that need investigation, stakeholders who weren’t in the room but should be consulted, processes that need their own dedicated session.

After the Session

The wall is not the artifact. The artifact is the writeup you produce afterwards. Within a few days, turn the photo into a digital version (Miro, Excalidraw, or even a simple markdown timeline). Annotate the hot spots. Distribute it to the participants and ask for corrections.

The digitized output then feeds whatever your next step is — an RFC, a domain model, a service boundary proposal, a backlog. Event storming is not a deliverable on its own; it’s an input to deliverables.

Variants Worth Knowing

The “events only” version is what I run for most discovery work. There are richer variants worth knowing about.

Big-picture event storming is the version above — broad scope, mostly events, used for understanding a whole business or large process.

Process-level event storming adds commands (blue), actors (yellow), policies (purple), and read models (green). It’s more structured and produces a more actionable artifact, but it requires participants who can hold more concepts at once. I use this for the second session on a domain, not the first.

Design-level event storming is the most detailed version, including aggregates, invariants, and bounded context candidates. This is what you use when you’re deciding the actual architectural shape of a system. It’s also where event storming starts to look most like classical DDD modeling.

For most consultative discovery work — the kind I covered in earlier posts — big-picture event storming is the right tool. The fancier variants are for when you’ve already converged on what to build and need to design how.

When Event Storming Is the Wrong Tool

Event storming is not a universal tool. It’s wrong for:

• Domains with very low complexity. If you can describe the workflow on a napkin, you don’t need a workshop. Just write the doc.
• Truly ambiguous problems. If you don’t know what events exist yet — for example, in early-stage product discovery before any process is established — event storming will produce hollow stickies. Use other discovery formats first.
• Strongly hierarchical cultures where junior people won’t speak up. The format depends on parallel contribution. If the senior person in the room is going to write all the stickies and everyone else will defer, you’ve lost the value. Run smaller, peer-level sessions first.
• When the real disagreement is political. If the conflict is “team A wants this project, team B wants a different project,” event storming won’t help. The disagreement isn’t about the domain.

Common Pitfalls

The session that becomes a meeting. People sit down, start discussing, and never get to the wall. Event storming is a standing workshop. Keep people on their feet. Keep them writing. Discussion follows stickies; stickies don’t follow discussion.

The dominant voice. One participant takes over and starts narrating “what happens.” Within ten minutes, the wall reflects their mental model and no one else’s. The facilitator’s job is to redirect — “let’s hear from someone who hasn’t put a sticky up yet.”

Treating the wall as the deliverable. The wall is throwaway. The understanding it produced is the deliverable. Don’t try to make the wall pretty. Don’t preserve it forever. Photograph it, write up the insights, and let the artifact be a working document.

Over-formalizing the first session. New facilitators often want to use every color, follow every rule, produce something architecturally rigorous. Don’t. The first session is for the team to learn the format and for the domain to surface. Color discipline can come later.

Skipping the writeup. A great session that doesn’t get documented is mostly wasted. Spend the same time on the writeup that you spent on the workshop, or close to it. The writeup is what stakeholders who weren’t there will actually read.

Inviting only engineers. A room full of engineers will produce a system diagram, not a business map. You need at least one or two people whose daily work is the actual domain — operations, customer success, finance, whatever applies.

Wrapping Up

Event storming is one of those techniques that sounds gimmicky until you’ve run a session and watched a three-month argument resolve itself in front of a wall. The barrier to trying it is genuinely low — sticky notes, markers, and a couple of hours — and the worst case is that you spend an afternoon with stakeholders mapping something you already knew. The best case is that you discover your real product is not the one in your roadmap.

Two posts left in the December series. Next up, a retrospective specifically on what 2023 did to engineering tooling — Copilot Chat, Cursor, GPT-4, and what I actually changed about my workflow this year.