The hardest part of building software is not writing code. It’s understanding what to build.
I’ve facilitated dozens of workshops with enterprise teams — some building new products, some untangling decades of legacy processes. The pattern is always the same: we have infinite tools to write code faster, but almost nothing to help us understand the domain faster.
Event Storming fills that gap. And in my experience, it’s the single most effective workshop format for getting cross-functional teams to stop talking past each other.
Watch the 30-second summary
Auto-generated summary — read the full article below for details.
What is Event Storming?
Event Storming, created by Alberto Brandolini, is a collaborative workshop format for exploring complex business domains. It’s the most effective method I’ve used for building shared understanding across teams, surfacing hidden assumptions, and identifying the right problems to solve.
“A network of interdependent agents influencing each other” — Alberto Brandolini’s definition of a complex domain.
In practice, a complex domain arises when tasks are carried out in multiple steps, involving several teams. Think of a recruitment process: HR, hiring manager, team members, and security all evaluate a candidate from different perspectives. The decision-making is collaborative, outcomes are not entirely predictable, and each situation requires a different approach.
When a domain is complex, the real challenge in software projects is not writing code faster — it’s understanding the business processes more quickly. It’s about identifying the right problem to solve.
The Building Block: Domain Events
Event Storming is built on a single primitive: the Domain Event. A Domain Event is something that happens and is relevant to the business.
Examples: Order Placed, Invoice Sent, Candidate Interviewed, Payment Failed.
Events are written in past tense on orange sticky notes and placed along a timeline. That’s it. The rest of the method builds from there.
Three Levels of Event Storming
Event Storming can be done at different levels depending on what you’re trying to achieve:
- Big Picture — Explore a complex business domain collaboratively. Useful when the scope is large or unclear.
- Process Modeling — Detail a specific business process from start to finish. Useful when the starting point and goal are clear.
- Software Design — Extend Process Modeling to design the architecture, including aggregates, commands, and bounded contexts.
Each level introduces new notation elements, but all are grounded in Domain Events placed on a timeline.
Big Picture Event Storming
The main purpose is to maximize learning. You’re not designing software yet — you’re building a shared mental model of the business.
When to use it
- Project kickoff
- Startup kickoff
- Organization reboot
- Onboarding new team members
- Retrospectives
Preparation
- Frame the problem. Confirm Big Picture is the right method. What’s the scope? What outcome do we expect?
- Invite 5–10 people (up to 20 if needed). Mix business and IT. Ensure the group includes people who can both answer and ask the hard questions.
- Room setup. People must stand and move freely. You need at least 8 meters of wall space. Use a plastic roll — most whiteboards aren’t wide enough. Remove the chairs.
The Workshop Flow
1. Kick-off (10 min)
Brief introductions. Optionally, a 20-minute warm-up on a familiar process (ordering a pizza works). Present goals, align on objectives:
“We’re going to explore the business process as a whole by placing relevant events along a timeline. We’ll highlight ideas, risks, and opportunities along the way.”
Keep the method explanation minimal. Display a legend and briefly walk through it.
2. Chaotic exploration (30 min)
Everyone writes Domain Events on orange sticky notes and places them on the wall simultaneously. This phase will feel chaotic — that’s the point. Structure comes later.
Good prompts to get people started:
- “Do you receive payments?”
- “Are contracts signed at some point?”
Don’t worry about capturing every event. Missing items are always added later.
3. Enforce the timeline
Now participants collaborate to arrange all events on a single timeline, left to right. They add missing events, place Hotspots (problems in red) and Opportunities (ideas in green).
Useful sorting strategies:
- Pivotal Events — anchor points in the flow
- Swimlanes — parallel activities by department
- Temporal Milestones — “end of month”, “quarterly close”
- Chapter Sorting — group by themes or phases
When disagreements arise, write a red Hotspot and move on. Revisit later.
4. Explicit walkthrough
Participants take turns as narrators. Each person walks along the timeline and explains the chain of events. The rest challenge unclear parts, fill gaps, suggest improvements. Keep turns to 5–10 minutes.
This step often takes the most time — a few hours is normal.
5. Reverse narrative
Do a final pass from end to start. For an invoice to be paid, it must first be sent. This reveals missing events every time.
6. Problems & Opportunities
Dedicated time for participants to focus on identifying problems and opportunities. Give the group 10–15 minutes to reflect and add notes.
7. Arrow Voting
Give each participant 2–3 arrow votes. Pick the two most urgent problems or opportunities to focus on. The result is visual and powerful — usually a few top issues stand out just by glancing at the wall.
Process Modeling Event Storming
Process Modeling shifts from broad exploration to detailed design of a specific business process. A smaller group (4–8 people) zooms in on a single end-to-end process.
The grammar
Unlike Big Picture, Process Modeling follows a precise, repeatable pattern:
Event → Policy → Command → System → Event
If the policy requires human intervention: Policy → [Human] → [Read Model] → Command
Key elements
- Policy (lilac) — A business rule triggered by an event. “Whenever X, then Y.”
- Read Model (green) — The information a user needs to make a decision.
- Command (blue) — An intent to change the system’s state. Phrased as verb + noun:
Place Order,Cancel Subscription. - System (pink) — A software service or external party treated as a black box.
Avoiding vague commands
Beware of Check, Verify, Review. These usually hide either:
- A missing Read Model (the user is trying to see something before acting)
- An unclear state change (rephrase:
Check Order→Mark Order as Checked)
Software Design Event Storming
This is where Event Storming meets Domain-Driven Design directly. The goal: identify Bounded Contexts and Aggregates.
From Process Model to Software Design
- Replace pink System sticky notes with yellow Aggregates for features you plan to build.
- External systems stay pink — those are outside your responsibility.
This small visual change transforms your process map into a blueprint for your system’s architecture:
- Pink Systems = external black boxes you interact with
- Yellow Aggregates = internal white boxes you design and own
Defining the Aggregates
After the session:
- Isolate and consolidate — Move all Aggregate notes to a clean area. Merge duplicates.
- Define boundaries — For each Aggregate, collect all Commands it handles on one side, all Events it emits on the other.
This layout visually defines the Aggregate’s public API — what it accepts and what it produces. Missing lifecycle steps become obvious: if you see Update Shipping Address but no Create Order, something is missing.
Key Takeaways
- The hardest problem in software is understanding the domain, not writing the code
- Event Storming is the fastest way to build shared understanding across silos
- Start with Big Picture when the scope is unclear — it surfaces inconsistencies automatically
- Use Process Modeling when you have a clear process to detail
- Use Software Design when you’re ready to define bounded contexts and aggregates
- Disagreement during the workshop is a feature, not a bug — it surfaces hidden assumptions
- The output is not the sticky notes — it’s the conversations that happen around them
Resources
- Introducing Event Storming — Alberto Brandolini’s original blog post
- Introducing Event Storming — the Leanpub book
- EventStorming.com — official site
Any opinions in this article are my own.