
## Before we start — the one thing to hold onto

Most teams think their biggest problem is documentation. Nobody wrote down how the system works. Nobody knows what triggers what. They try to fix it by reading the code, interviewing senior developers, or drawing diagrams nobody agrees on.

**Your system is a sequence of things that happened — domain events. If you can name every significant event in order, you understand the system. If you can't, no diagram will save you.**

That one idea changes everything. It turns system discovery from an archaeology project into a collaborative conversation — one where business experts and engineers are equally useful, on the same day, in the same room.

Keep it in mind.

---

## Purpose

The goal of this workshop is concrete: build a shared model of your business system — its events, its processes, its boundaries, and its pain points — in a single day, with the people who understand it best.

I've seen organisations spend months writing requirements documents that engineers couldn't implement and business stakeholders didn't recognise. The document wasn't the problem. The process was. Requirements written by one group and handed to another will always lose something in translation. Event Storming removes the translation layer entirely.

You'll leave with a timeline of every significant domain event in your system, a map of hotspots where complexity and confusion concentrate, and the beginning of a shared language that survives the workshop room.

---

## Who Should Attend

This workshop only works when the right people are in the room together. That's the entire point.

- Domain Experts who know the business process (not just in theory — the people who run it)
- Developers and Engineers who build and maintain the system
- Product Managers and Business Analysts
- Solution Architects and Tech Leads

**Typical team size:** 8-15 participants (larger is possible with co-facilitation)
**Format:** In-person strongly preferred — sticky notes, wall space, and physical presence matter
**Wall space required:** At least 8 metres of continuous surface (physical or virtual equivalent)

### Try it yourself — The event timeline

Pick one business process your team owns end to end. Write down every significant thing that *happened* — not what the system does, not what users can do, but what occurred. Use past tense. "Order placed." "Payment confirmed." "Shipment dispatched." "Delivery failed."

If you get stuck before ten events, you don't know your own process as well as you think. That's why this workshop exists.

---

## What You'll Achieve

By the end of this workshop, you will have:

- A complete event timeline of your domain — every significant business event in sequence
- Hotspot identification — where complexity, confusion, and disagreement concentrate
- Aggregate boundaries emerging from the events themselves, not from upfront design
- Process ownership canvas — which team or role is responsible for each stage
- Command and policy mapping — what triggers each event, what each event triggers
- A prioritised list of the questions that need answering before design decisions are made

These aren't outputs to file away. They're the conversation starter your next three months of design work will reference constantly.

---

## Typical Outcomes

**Immediate outcomes (within 1 week):**
- Shared event timeline visible to technical and non-technical stakeholders
- Hotspot list with initial ownership assigned
- Identified top 3 areas of process confusion or missing system behaviour

**Short-term outcomes (within 1 month):**
- Design decisions anchored in discovered events, not assumed requirements
- Aggregate and bounded context boundaries informed by the event model
- Fewer "that's not how it works" surprises in sprint reviews

**Long-term outcomes (3-6 months):**
- Faster feature design — teams start from events, not blank-page requirements
- Reduced rework from misunderstood business processes
- Shared vocabulary between engineering and the business that outlasts the workshop

---

## Workshop Structure

**Morning (3 hours): Chaotic Exploration**
- Introduce domain events — what they are, how to write them
- Unstructured event generation — everyone puts events on the wall simultaneously
- No filtering, no debate — quantity over quality at this stage

**Midday (1 hour): Sorting and Sequencing**
- Arrange events into a timeline
- Surface duplicates, contradictions, and gaps
- Mark hotspots — places where nobody agrees or everyone looks uncomfortable

**Afternoon (3 hours): Structured Exploration**
- Add commands — what triggered each event
- Add policies — what each event triggers in response
- Add actors — who or what issues each command
- Begin identifying aggregate boundaries from natural event clusters

**End of day (1 hour): Synthesis**
- Name the processes, identify the owners
- Agree the top questions the model raised
- Define next steps — what gets designed first

**Total duration:** 1 full day
**Adjustable:** Yes — Big Picture Event Storming (half day) for high-level discovery; Process Modelling (full day) for detailed system design

### Try it yourself — The hotspot question

Think about the last feature your team shipped that caused unexpected problems. At what point in the business process did the problem occur? Was that point visible in your requirements? Was it even on anyone's radar before the bug report came in?

Most teams I work with find their biggest surprises hide in the transitions between events — where one team's output becomes another team's input and nobody owns the seam.

---

## Prerequisites & Preparation

**Before the workshop:**
- Identify the business process or system area to explore (scope matters — too broad and the day is wasted)
- Confirm domain experts are attending — without them, engineers model assumptions, not reality
- Prepare wall space and materials (physical: large paper rolls, orange/blue/yellow sticky notes; virtual: Miro or equivalent)

**Recommended team composition:**
- 2-3 Domain Experts who run the business process day-to-day
- 2-3 Developers who build or have built the system
- 1-2 Product Managers or Business Analysts
- 1 Tech Lead or Architect
- 1 Facilitator (ideally experienced with DDD — this is not a self-facilitated session)

---

## How to know if this landed

You'll know this has landed when a developer and a domain expert point to the same sticky note and mean exactly the same thing. When someone finds a hotspot in an area of the system everyone assumed was simple. When the business process expert says "I didn't know that's what the system was doing." When the developer says "I didn't know that's what the business was expecting." Both of those moments, in the same session, in the same room.

---

## What changes when the mental model clicks

I've run this session with teams who had built the same system — or thought they had. Developers who described it in terms of tables and services. Business stakeholders who described it in terms of customers and transactions. Neither group was wrong. They just couldn't see each other's model. Event Storming puts both models on the same wall and forces them to reconcile.

What changes after this workshop:

Teams stop designing systems in isolation and start discovering them together. The chaotic exploration phase tends to be the moment things click — the room is loud, sticky notes are flying, and for the first time in months, the domain expert and the senior developer are having the same conversation. Not adjacent conversations. The same one.

The hotspot mapping tends to immediately change how teams prioritise. They stop working on what's loudest in the backlog and start working on what's most confused in the model. Their designs get more accurate. Their estimates get more honest. They stop being surprised by complexity they could have found on day one.

---

## Book a Workshop

Ready to get your whole team modelling the same system, in the same room, on the same day?

→ **[Book a Workshop](https://calendly.com/naveen-innoventurex/free-consultation-with-naveen)**

or

→ **[Contact me directly](/contact)**

*1-day facilitated workshop includes chaotic exploration, event sequencing, hotspot mapping, command and policy modelling, aggregate boundary identification, and a prioritised next-steps canvas.*

Get your developers, domain experts, and business stakeholders in the same room, speaking the same language, discovering the same system — in one day.

Event Storming Workshop

Stop designing systems around databases and frameworks. Start designing around your business domains — and watch your architecture conversations change overnight.

Event Storming Workshop

Related Workshops