In one minute
Discover a domain process collaboratively by arranging meaningful events in time.
Participants write past-tense domain events, order them, mark hotspots and decisions, then identify commands, actors and boundaries. The wall is a discovery artifact, not a complete executable design.
The problem it addresses
Specialists hold incompatible versions of a workflow, while software requirements hide exceptions.
A food-delivery platform believes refunds start with customer complaints, but warehouse staff report that stock substitutions occur before the customer is notified.
When to use it
- Use EventStorming when specialists hold incompatible versions of a workflow, while software requirements hide exceptions.
- The team can examine: A bounded process, people with different knowledge, event evidence and a facilitator.
- A relevant situation is: A food-delivery platform believes refunds start with customer complaints, but warehouse staff report that stock substitutions occur before the customer is notified.
When not to use it
Do not use it to replace evidence, accountable judgement or affected people's participation.
Turning the workshop into a software architecture debate before participants agree on what happens.
Inputs required
A bounded process, people with different knowledge, event evidence and a facilitator.
Step-by-step process
1. Bound the decision and name its owner.
Write the scope, decision owner and people who can veto or revise the result before starting the workshop.
2. Collect the necessary evidence and affected perspectives.
Collect and date the necessary evidence: A bounded process, people with different knowledge, event evidence and a facilitator.
3. Choose a process boundary and outcome.
Agree where the story begins and ends and invite people who know different parts of that story.
4. Collect domain events in past tense.
Write business events as things that have happened, such as ‘Payment failed’, rather than screens or proposed features.
5. Order events and mark uncertainty or conflict.
Arrange events in time, then mark missing transitions, disagreements and uncertain order as hotspots.
6. Add triggering actions, actors and policies.
Add the actions that trigger events, the actor or system responsible and any policy that changes the path.
7. Validate with real cases and turn hotspots into questions.
Replay two real cases through the wall and turn each unresolved hotspot into a research or design question.
8. Record the output, next test and review trigger.
Store the artifact with its evidence links, owner, bounded next test and date or trigger for review.
AI automation lens
AI may sort authorised notes and expose missing evidence. It must not invent observations, silently decide for affected people or present a generated map as validated.
Visual model
Text alternative: Choose a process boundary and outcome; Collect domain events in past tense; Order events and mark uncertainty or conflict; Add triggering actions, actors and policies; Validate with real cases and turn hotspots into questions.
Interactive example
Scenario: A food-delivery platform believes refunds start with customer complaints, but warehouse staff report that stock substitutions occur before the customer is notified.
Worked answer: Map order accepted, item unavailable, substitute chosen, notice sent, consent received and refund issued; expose the missing consent event.
Facilitation notes
Record disagreements before synthesising; ask whose evidence is missing; state who may revise the result.
Expected output
- An inspectable decision artifact, its assumptions and evidence, a responsible owner, a bounded next test and a review date.
- Validate with real cases and turn hotspots into questions.
- A named owner, test and review date.
Common mistakes
Turning the workshop into a software architecture debate before participants agree on what happens.
Quality checklist
- The decision and system boundary are explicit.
- Affected people and alternative accounts are included.
- Each important claim has a source or is marked as an assumption.
- An owner, safeguard and disconfirming signal are named.
Template
Knowledge check
Question: What mistake would undermine this method in the scenario?
Answer: Turning the workshop into a software architecture debate before participants agree on what happens.
Related tools
References
- EventStorming — method source (opens in a new tab). Accessed 2026-09-28.
- Independent practice reference (opens in a new tab). Accessed 2026-09-28.
Method profile
The method structures a discussion and a test; it does not establish causal proof or guarantee success.