Speaking Engineering: Disambiguation Frameworks for Business Owners
Module 3 of 7 Beginner 25 min

Reading the Room — How Event Storming Surfaces What Actually Happens

Prerequisites: When Everyone Means Something Different — Why Disambiguation Matters, The Shared Language Toolkit — DDD Core Vocabulary for Business Owners

What You'll Learn

  • What event storming is and why it reveals things that written documentation cannot.
  • The sticky-note color notation — what each color means and how to use it.
  • Why flagging disagreement (rather than resolving it immediately) is the most valuable thing a session can produce.
  • What you, as a business expert, are expected to contribute — and why your knowledge is the raw material the workshop runs on.
  • The difference between Big Picture event storming (whole domain, many people) and Process Modeling event storming (one process, smaller group).

Why This Matters

This framework resolves the ambiguity of what actually happens in our business by making the timeline of domain events (things significant that happened in the business, written in past tense — for example, "Order Placed" or "Invoice Approved") visible and shared.

You have probably been in a project kickoff where everyone agreed on the goal, produced a requirements document, and then discovered three months later that engineering built something that worked perfectly — for a business process that nobody actually follows. The problem was not that anyone lied. The problem was that each stakeholder described the process from their own vantage point, and nobody forced those accounts into a single shared timeline. Event storming fixes this by putting everyone in the same room, at the same wall, placing sticky notes in the order things actually happen. Disagreements become visible within minutes, not months.

Core Concept

Event storming is a collaborative workshop in which business experts and engineers together map the domain (the specific area of business a system is built to support) by placing domain events on a long chronological timeline. Alberto Brandolini invented the format around 2013. The physical setup is deliberately low-tech: a long roll of paper on a wall, colored sticky notes, and markers. No software, no slide decks, no pre-written specifications.

The central insight is that a timeline is an unusually honest artifact. When you write a document, you describe the process as you understand it from your position. When you place sticky notes on a wall alongside colleagues from other departments, contradictions immediately surface: your "Approval Granted" note and a colleague's "Approval Granted" note land at completely different points on the timeline, because they refer to different approvals — and nobody knew that until this moment.

The sticky-note color conventions

Each color in event storming carries a specific meaning. The contract for this curriculum defines these colors as follows, and you should expect to see them used consistently in any well-run session:

  • Orange — Domain events. Past-tense statements of significant things that happened: "Quote Requested," "Risk Assessed," "Policy Issued." These are the spine of the entire session.
  • Blue — Commands. The action that triggered the event. "Submit Application" triggers "Application Submitted." Commands tell you what caused the event.
  • Yellow — Actors or people. The person or group who issued the command. A yellow note reading "Sales Agent" next to a blue "Submit Application" command explains who did it.
  • Pink — External systems. Another software system or service that sent a command or received an event. The billing platform, the payment gateway, the regulatory reporting system.
  • Purple — Policies or business rules. Automated logic that fires when an event occurs: "When Claim Filed, notify Underwriting within 24 hours." Policies bridge events to the commands they automatically trigger.
  • Red — Hotspots. A red sticky note placed to mark disagreement, uncertainty, or a question that needs resolution later. Not a blocker — a discovery. More on these below.

The timeline and what it reveals

Events flow left to right in the order they occur in the business. The act of physically placing sticky notes in sequence does three things that documentation cannot:

  1. It exposes gaps. If nobody places an event between "Policy Issued" and "Premium Collected," someone will ask: "What happens in between?" That question surfaces a handoff that was invisible until the timeline forced it.
  2. It reveals parallel flows. Two separate chains of events may run simultaneously — the billing process and the claims process, for example — and a timeline makes that concurrency obvious.
  3. It makes conflicts tangible. Two people placing contradictory events at the same point on the wall cannot both be right. The conflict is visible and unavoidable.

Hotspots: the most valuable output

When participants disagree about when an event occurs, what it means, or who triggers it, someone places a hotspot — a red sticky note — at that point on the timeline. The group does not stop to debate it. They record it, flag it, and keep moving.

This is counterintuitive. Shouldn't you resolve disagreements when you find them? Not in an event storming session. Stopping to debate every conflict kills momentum and often produces a surface-level compromise that masks a deeper problem. The hotspot says: "Something important is unresolved here. We will investigate it later with the right people and the right information." At the end of a session, the clusters of hotspots tell you exactly where your most dangerous assumptions live.

The two modes: Big Picture and Process Modeling

Event storming runs at two different scales depending on what you need to learn.

Big Picture event storming involves the full range of stakeholders — often 15 to 30 people — and maps an entire business domain or a major business line from end to end. The goal is shared understanding and boundary discovery, not precision. You might run a Big Picture session at the start of a new product initiative to make sure every department sees the same overall flow before anyone writes a single line of code.

Process Modeling event storming zooms in. A smaller group of 4 to 8 people maps one specific process in detail, adding commands, actors, policies, and external systems. The goal here is precision and design: by the end, the group has a detailed, shared model of how one process actually works.

Concrete Example

Let's walk through what a Big Picture event storming session looks like for Meridian Insurance as they plan their new small business property insurance product.

The team assembles: a Sales manager, an Underwriting analyst, a Claims lead, and two engineers. They unroll a long sheet of paper on the conference room wall and start placing orange sticky notes — domain events — in roughly the order they believe things happen.

The initial timeline takes shape quickly:

  1. "Quote Requested" (Sales places this)
  2. "Risk Assessed" (Underwriting places this)
  3. "Policy Issued" (Underwriting again)
  4. "Premium Collected" (a Finance representative adds this)

So far, so good. Then the Claims lead starts adding her side of the story:

  1. "Claim Filed"
  2. "Assessment Completed"
  3. "Approval Granted"
  4. "Settlement Paid"

When "Approval Granted" goes on the wall, the session stops. The Underwriting analyst says: "Wait — we already have an approval. It happens between Risk Assessed and Policy Issued. That's when we approve coverage." The Claims lead shakes her head: "That's not what I mean. My 'Approval Granted' is when we authorise the payout. It's completely different."

Same words. Two completely different events. A red hotspot sticky goes up next to both occurrences of "Approval Granted." The group does not debate it — they note it and keep moving. But now the problem is visible on the wall in a way that no requirements document had ever made clear.

Then someone notices a gap. Between "Policy Issued" (step 3) and "Premium Collected" (step 4), there is nothing. The Sales manager assumed billing happened automatically. The Finance representative assumed the agent triggered it. Nobody had mapped that handoff. A hotspot goes up there too.

By the end of a two-hour session, Meridian has a timeline, a cluster of hotspots around "approval," and an unexpected gap in the billing handoff. These are the discoveries that justify the session. The team now knows exactly where to focus their next conversations — and they know it together.

Analogy

Think of event storming like detectives reconstructing a crime from witness statements.

Each witness saw a different piece of what happened. The patrol officer who responded saw the scene after the fact. The shop owner across the street saw who entered the building. The accountant upstairs heard voices at a particular time. No single witness has the complete picture, and each one describes what they saw using their own frame of reference.

A skilled detective does not read all the statements in isolation and write a report. They bring the witnesses together, ask each one to place their account on a shared timeline, and watch what happens when the accounts contradict each other. Those contradictions are the clues.

In event storming, your Sales team, your Underwriting analysts, your Claims leads, and your engineers are all witnesses to the same business process. Each one knows their piece deeply and the other pieces only dimly. The session is the interview. The timeline on the wall is the shared reconstruction. And the hotspots are the contradictions that tell you where the truth is still hidden.

Going Deeper

Why the physical format matters. You might wonder: can't we do this in a spreadsheet, or in a digital tool? You can, and distributed teams often do. But Alberto Brandolini designed the workshop around physical sticky notes deliberately. The act of walking to a wall and placing a note is more cognitively engaged than typing into a shared document. People who are standing and moving participate differently than people who are sitting and typing. The low-tech format also levels the playing field: the person with the most impressive slide deck is no longer at an advantage.

What comes after a session. The output of a Big Picture event storming session is not a final artifact — it is the starting point for deeper work. The clusters of events on the timeline often hint at bounded context boundaries (clearly defined boundaries within which a specific team uses consistent terminology and owns a coherent set of capabilities). In the Meridian example, the events around the Policy Issuance cluster belong to one context; the events around Claim Settlement belong to another. Making those boundaries explicit is exactly what the next module — context mapping — is about.

The facilitator's role. Someone needs to keep the session moving: ensuring events are written in past tense, preventing debates from stalling the room, and placing hotspots when disagreements surface. In many organizations this is an experienced practitioner or an outside consultant for the first few sessions. Once a team has run two or three sessions, they often self-facilitate successfully.

When event storming is not the right choice. If you already have a clear, agreed-upon process model and just need to prioritize which features to build first, event storming is probably overkill. It is a discovery tool, not a planning tool. If the question is "what order do we build things in?" rather than "what actually happens in this business?" you may want user story mapping instead.

Common Misconceptions

Misconception 1: "Event storming is only for developers."

This is the most damaging misunderstanding, because it causes the people whose knowledge matters most — domain experts — to opt out. Event storming was invented to bridge the gap between business and engineering, and it only works when business experts are in the room. Engineers contribute structure and ask good questions. But business owners provide the ground truth about how the domain actually works. Without you, the session produces a technically coherent model of a process nobody actually follows.

Misconception 2: "A session with unresolved hotspots is a failure."

Actually, the opposite is true. A session that ends with no hotspots usually means people were too polite to surface their disagreements. Hotspots are discoveries, not failures. A session that produces ten clear hotspots has given the team a precise map of where the riskiest assumptions live — and that is far more valuable than a session that produces a tidy-looking timeline hiding unresolved conflicts.

Misconception 3: "You need to understand DDD and software architecture to participate."

You do not. The only concept you need to bring into the room is "domain event" — past-tense, significant things that happened in the business. You learned this in the previous module on DDD core vocabulary. You do not need to know anything about software patterns, APIs, code, or systems design. The session is intentionally language-agnostic in the sense that no implementation jargon is required. What is required is your knowledge of how the business actually works. That is your expertise, not the engineers'.

Check Your Understanding

  1. A colleague tells you: "We have detailed process documentation. There's no point in running an event storming session." What would you say in response?
Reveal answer Documentation describes a process as one person (or group) understood it at one point in time. Event storming brings multiple stakeholders into the same room and forces their accounts into a shared timeline, which immediately surfaces conflicts and gaps that no single document can reveal. The value is not in the timeline artifact itself — it is in the collaborative reconstruction that produces it.
  1. During a Meridian event storming session, two participants disagree about whether "Approval Granted" refers to a coverage decision or a payout authorisation. What is the correct thing to do in the moment?
Reveal answer Place a red hotspot sticky note at that point on the timeline, note the disagreement briefly, and keep moving. Do not stop to debate or resolve it in the session. The hotspot marks it as a discovery to be investigated later with the right people and evidence. Stopping to resolve every conflict in the room kills momentum and often produces shallow compromises.
  1. What is the difference between a domain event (orange) and a command (blue)? Give an example of each using the Meridian insurance scenario.
Reveal answer A domain event records something that already happened — it is past tense and records a fact: "Risk Assessed," "Policy Issued." A command records the action that caused the event — it is the instruction that was issued: "Assess Risk," "Issue Policy." Commands explain why an event occurred; events record that it occurred. In the Meridian scenario, the command "Submit Application" (blue) triggers the event "Application Submitted" (orange).
  1. Why does the Big Picture format involve 15–30 people rather than just the core team?
Reveal answer Because the full business process crosses departmental boundaries, and no single department sees the whole picture. Sales sees the customer acquisition flow; Underwriting sees the risk assessment flow; Claims sees the settlement flow. Bringing all of them together in one session is the only way to produce a timeline that reflects the real end-to-end process rather than each group's local view of it.
  1. At the end of a Meridian event storming session, you notice that the events around Policy Issuance and the events around Claim Settlement have clustered into two distinct groups with very few connections between them. What does this suggest, and where does it lead next?
Reveal answer The clustering suggests that these two groups of events may belong to different bounded contexts — areas of the business with distinct terminology, ownership, and responsibilities. This is exactly the input for the next step: context mapping, which takes the boundaries hinted at by the event clusters and makes them explicit, naming who owns each context and how the contexts relate to each other.

Key Takeaways

  • Event storming is a collaborative workshop in which domain experts and engineers place domain events on a shared timeline to discover how a business process actually works — gaps, conflicts, and all.
  • The sticky-note color system — orange for domain events, blue for commands, yellow for actors, pink for external systems, purple for policies, red for hotspots — is the grammar that makes the session legible.
  • Hotspots (red notes marking disagreements or open questions) are the most valuable output of a session, not a sign of failure. They map your riskiest assumptions.
  • As a business expert, you are not an observer in an event storming session — you are the primary source. Engineers ask questions; you provide the ground truth.
  • Big Picture event storming explores an entire domain with a large group; Process Modeling event storming zooms into one process with a smaller group. The two formats serve different questions.

References