Event Storming in Context

Core Concepts

Event Storming Is a Starting Point, Not a Complete System

Event Storming excels at rapid, cross-functional exploration of a business domain. It surfaces domain events, commands, actors, and policies in a format that builds shared understanding across technical and non-technical participants. What it does not do as well: it does not structure user journeys for release planning, it does not produce executable acceptance criteria, it does not narrate actor collaboration patterns with precision, and it does not answer strategic questions about why something matters to the business.

These gaps are not weaknesses to fix—they are places where other techniques take over. Event Storming works most effectively as the foundational catalyst for a discovery sequence, with other techniques applied downstream to deepen, structure, or operationalize the shared understanding it creates.

Domain Storytelling

Domain Storytelling is a collaborative modeling technique focused on how actors—people and systems—interact and communicate. Domain experts narrate domain stories in spoken language while a moderator records those stories as visual diagrams using icons, arrows, and text annotations (a pictographic language).

Where Event Storming uses an open brainstorming format to build a timeline of events on a wall, Domain Storytelling uses a structured, narrative-driven format guided by a moderator. This makes Domain Storytelling more accessible to non-technical stakeholders and particularly well-suited when the critical domain question is not "what happens?" but "who does what with whom, and how do they communicate?"

Example Mapping

Example Mapping, developed by Matt Wynne at Cucumber, is a structured conversation technique for specifying a single user story using concrete examples. The session produces four card types: stories (yellow), rules (blue), examples (green), and questions (red). Sessions are designed to be fast—typically 25 to 30 minutes per story. If a session runs longer, it signals that the story is too large or insufficiently understood, prompting decomposition or further discovery.

The outputs of an Example Mapping session are directly translatable into Gherkin acceptance tests for BDD, producing living documentation that functions as both specification and automated regression coverage.

User Story Mapping

User Story Mapping, developed by Jeff Patton, organizes stories around user journeys rather than feature lists. The map has two axes: user activities (backbone) run horizontally, and story details and features (supporting stories) stack vertically beneath each activity. This structure enables horizontal slicing for release planning—teams can deliver coherent working capabilities aligned to user workflows, rather than isolated technical increments.

The output is a prioritized backlog explicitly grounded in user value delivery, not just technical completeness.

Impact Mapping

Impact Mapping provides the strategic business context that none of the other techniques addresses directly. It answers four questions: Why does this change matter (Goal)? Who is affected or can influence the outcome (Actor)? What behavior change is needed (Impact)? What should be built to enable that behavior change (Deliverable)?

Event Storming focuses on understanding what happens in a domain; Impact Mapping answers why any of it should change. Together they ensure that discovery work is anchored to strategic intent rather than just operational fluency.

---

Compare & Contrast

Fig 1

Event Storming vs. Domain Storytelling

Both techniques build shared domain understanding, but they do it differently and answer different questions.

Event Storming is unstructured and timeline-oriented: participants place orange sticky notes representing domain events and the group organizes them into a causal sequence. The facilitator does not control what gets surfaced—exploration is emergent.

Domain Storytelling is structured and narrative-oriented: a moderator records domain stories told by domain experts as pictographic diagrams, capturing who passes what to whom and for what purpose. The output reflects how actors communicate, not just what changes in the system.

Choose Event Storming when you need a rapid, broad view of a domain and want to surface bounded contexts, hotspots, and temporal flows. Choose Domain Storytelling when the critical understanding is how multiple actors coordinate—especially when collaboration patterns and communication protocols are what needs modeling.

Event Storming vs. Example Mapping

These two techniques operate at very different scopes. Event Storming works at the domain or subdomain level. Example Mapping works at the individual story level. They are not alternatives; they are sequential layers.

Running Event Storming first establishes domain clarity; Example Mapping then refines the rules and policies attached to specific events and commands. Event Storming surfaces what the system does; Example Mapping specifies precisely how a single behavior should work, including edge cases and failure modes.

Event Storming vs. User Story Mapping

User Story Mapping organizes user activities on a horizontal backbone and stacks supporting stories beneath each activity. This structure is excellent for release planning but requires pre-existing shared understanding to populate effectively.

Event Storming accelerates User Story Mapping precisely because it builds that shared understanding first. Domain events and commands from an Event Storming session directly correspond to user actions and can be transferred into story map entries. Teams that skip Event Storming and attempt User Story Mapping cold spend far more time negotiating terminology and domain basics.

Event Storming vs. Impact Mapping

Impact Mapping operates at the strategic level—above the domain model. It answers why a project matters, not what it does. Event Storming tells you what happens in a domain; Impact Mapping tells you which parts of that domain are worth changing and why.

The two are most powerful when used in sequence: Impact Mapping to establish strategic constraints before discovery, and again after Event Storming to prioritize which bounded contexts and commands are worth investing in.

---

Key Principles

1. Sequence by scope: start broad, then narrow. Each technique operates at a different level of resolution. Event Storming maps the domain at altitude. User Story Mapping organizes it into deliverable journeys. Example Mapping specifies individual behaviors with precision. Running them in this order is more effective than any single technique alone.

2. Let Event Storming outputs drive downstream inputs. Domain events and commands are not just artifacts of the Event Storming session—they are reusable inputs for User Story Mapping and Example Mapping. Treat the Event Storming output as a shared vocabulary, not a throwaway artifact.

3. Match technique to question type. Each technique answers a different kind of question. Reaching for Event Storming when you need actor communication patterns, or reaching for User Story Mapping when you need domain boundaries, wastes time and produces weak results. The right question determines the right technique.

4. Use Impact Mapping to guard against scope drift. Domain discovery creates energy. That energy can generate scope that has no strategic justification. Impact Mapping provides the strategic anchor that keeps the team focused on outcomes that matter to the business, not just areas that are intellectually interesting.

5. Unify the visual language to reduce context switching. Multiple techniques can share a common visual language—consistent color schemes and building blocks inspired by Event Storming notation—so that switching between techniques does not require participants to mentally reset. This is especially valuable when running sequential workshops over multiple sessions.

---

Worked Example

Scenario: Redesigning an Insurance Claims Process

A technical lead is brought in to help a mid-sized insurance company redesign their claims processing workflow. The existing system has fragmented documentation, multiple actor groups (claimants, adjusters, third-party assessors, and finance), and a backlog of competing feature requests with no clear strategic direction.

Step 1: Impact Mapping (half day)

Before any domain discovery, the team runs a short Impact Mapping session with senior stakeholders. The goal (Why): reduce claims resolution time by 30% within 12 months. Actors: claimants, adjusters, assessors. Key impacts: claimants should be able to self-serve status updates; adjusters should be able to assign assessors without email chains. This session produces a prioritized set of outcomes that will constrain scope throughout discovery.

Step 2: Big Picture Event Storming (full day)

The cross-functional team—including IT, claims operations, finance, and compliance—runs a Big Picture Event Storming session. The output is a full timeline of domain events from claim submission to settlement, with hotspots marking points of confusion or conflict. Two candidate bounded contexts emerge: Claims Triage and Settlement Processing. Several commands and events are flagged as directly relevant to the Impact Mapping outcomes.

Step 3: Domain Storytelling (half day, targeted)

The Claims Triage bounded context involves complex coordination between adjusters and assessors. A Domain Storytelling session is run specifically for this subdomain, with a moderator recording how adjusters communicate task handoffs to assessors today. The pictographic output reveals three informal communication channels that bypass the system entirely—a key insight that was not visible from the event timeline alone.

Step 4: User Story Mapping (one day)

Using the event timeline and the Domain Storytelling output, the team constructs a User Story Map organized around the adjuster's journey. Events and commands from the Event Storming session are directly translated into story map entries. The first horizontal slice—the MVP release—covers claim intake, automated status notifications, and assessor assignment. The backlog is immediately prioritized against the Impact Mapping outcomes.

Step 5: Example Mapping (ongoing, per story)

As stories move into development, each one passes through a 25-30 minute Example Mapping session before entering a sprint. The rules and examples from these sessions are written directly as Gherkin scenarios, producing automated acceptance tests. Stories that cannot be specified within the time limit are returned for decomposition.

The power of this sequence is not any single technique. It is the transfer of artifacts: Impact Mapping constrains scope. Event Storming builds the shared vocabulary. Domain Storytelling fills in the actor coordination gaps. User Story Mapping structures delivery. Example Mapping locks down behavior.