EventStorming
The most versatile Collaborative Modelling format
EventStorming is a family of Collaborative Modelling workshop formats that allows you to explore complex domains effectively and engagingly. It’s also one of our house specialities. Proudly invented here.
A bit of history

EventStorming was born more or less by chance around 2013 to draft complex software business processes in an Event-Driven way.
The initial name, “Event-based modelling”, originates from Vaughn Vernon’s IDDD Tour (notes from Jef Claes and Tom Janssens), where Alberto Brandolini was a guest trainer. The term “Event-based” was already used in Vaughn’s material, so a last-minute name change happened just before going on stage in Leuwen, and EventStorming was born.
(Yep, the official spelling is a single word: EventStorming, not Event Storming).
Given the audience’s enthusiastic response to the experiment, Alberto wrote the first blog post about the format.
That was the beginning of a rollercoaster. A small community of practitioners was born, and experiments and variations flourished. This led to many conference talks, the start of a book, and the adoption of EventStorming in several business domains worldwide.
The original idea was born with a Domain-Driven Design mindset. But the collaborative storytelling format based on orange events has proven very versatile over the years. Variations in the format performed very well in discovery and design-oriented workshops.
Key principles
The most effective conversations happen when modelling tools support people. However, traditional modelling tools like flipcharts and whiteboards constrain the space available and the number of items that can be discussed. A standard recommendation is to limit the number of items drawn on a diagram to seven or fewer. But this approach only works if your problem is small enough to fit in.

How do we solve big, rotten problems? How do we address issues that arise from dozens of interconnected factors?
As David Sibbet put it in his book Visual Meetings:
“Can’t do system thinking without visualisation.”
Big problems need visualisation even more than the small ones; we need different tools for that.
Digital modelling tools provide the illusion of unlimited modelling surfaces, but add new limitations. Screen size remains the same, but the digital experience introduces new blockers, such as tool familiarity and license costs. Even the best online modelling platforms introduce frictions and limit the communication bandwidth.
EventStorming breaks the space limitation while staying in the physical space. The paper roll provides the illusion of an unlimited modelling surface, and the lo-fi notation based on coloured sticky notes lowers the barrier to active contribution.
Put another way: there’s no need to lose detail if you have enough space. You can see the forest and the trees just by walking around the room.
Massive parallel contributions can quickly turn into a mess. The different formats have different facilitation strategies to keep the workshop in “the zone”.
Main recipes
The original proposition was about a single format, but over the years, three main flavours emerged:
- Big Picture EventStorming is a large-scale workshop aiming to discover the intricacies of an entire business line. It usually involves 15 to 30 people, depending on the domain complexity.
- Process Modelling EventStorming targets an end-to-end specific process (including its variations). You can use this format for discovery and/or design, and it typically involves a smaller interdisciplinary team
- Software Design EventStorming has a similar scope. The original format was intended to discover aggregates in Domain-Driven Design. Then it became a more sophisticated modelling tool, enabling the detection of boundaries and the design of robust, loosely coupled systems.
You can use the different formats individually–Big Picture is great for large-scale retrospectives, for example–or chain them. For instance, we can use Big Picture EventStorming to identify the most relevant area for improvement, then drill into it with Process Modelling EventStorming.
Sometimes, a more detailed format – such as Software Design EventStorming blends in, introducing technical discussion without displacing the business-driven conversation.
Let’s explore the formats with a little more detail.
Big Picture EventStorming
This format leverages the idea of unlimited modelling space to avoid the trap of unnecessary scope limitations. We need a system-level view and enough space to address systemic issues.
Most workshops focus on a specific business line. Still, it’s common to explore scenarios in which multiple business lines share (or compete for) resources or processes—for example, two business lines operating on a shared platform.
Depending on the organisation’s size, a different number of people would be involved. Typical numbers range between 15 and 30 participants.
Standard Steps
- Invite the right people. Experts and explorers. People with questions and people with answers. The more perspectives, the more insights.
- Provide an Unlimited Modelling Surface or the closest approximation. A plotter paper roll on a 10-12 metre straight surface is usually enough to describe most business lines end-to-end. Offer an abundant supply of markers and sticky notes.
- An initial round of chaotic exploration, where participants will contribute to the global narrative with the Events they know, should lay the foundation for the next steps. Now we have a mess to sort out.
- Enforcing the timeline is the first round of sorting. This is where the first relevant conversations usually happen, and a more robust structure emerges with Pivotal Events and Swimlanes. Structure won’t emerge without meaningful conversations. We’ll capture emergent frictions with magenta HotSpots.
- People and Systems would be the next ingredient in our growing narrative and are usually a source of more HotSpots.
- Now, we should have enough information for an explicit walkthrough. A narrator will try to tell a precise story to a picky audience. Meanwhile, a scribe will update the visible model in real-time with the necessary corrections.
Completing the walkthrough should give us a validated narrative: what is visible has been presented, corrected, refined, and approved. Great! Now everybody is on the same wide-scale page.
Custom Steps
The validated narrative is a versatile artefact that could be the perfect background for more interesting steps. You may pick the ones that are more suitable for your scenario:
- “Playing with value” allows you to visualise and discuss the steps and activities that deliver or destroy value for your customers, employees, stakeholders, etc.
- In “Problems and Opportunities,” we’ll explore explicit issues with the current model and propose solutions to address open problems or new ideas to tackle opportunities.
- Arrow Voting can quickly visualise the convergence on a specific issue, which is probably your organisation’s current main blocker.
- Extracting User Stories is a common step in Big Picture EventStorming during a software development project kick-off.
- Extracting Bounded Contexts is the perfect homework for your technical team to derive a Context Map from your EventStorming exploration.
- Visualising ownership may make the connection between your flow and your development teams’ areas of responsibility evident.
And the list can grow. AÂ validated narrative is an incredibly effective background for many types of discussion.
Typical scenarios
Big Picture EventStorming is by far the most versatile recipe. You can choose a combination of custom steps to design the most fitting experience. The workshop is a tool to serve your business needs, after all. Here are some common scenarios.
- It can be a key step in an Architecture Modernisation initiative to highlight the current tensions in your architectural landscape.
- You can use the Big Picture format to run a large-scale corporate retrospective that focuses on collaboration across departments. This typically occurs at pivotal moments in your company’s growth, such as transitioning to scale-up after a major merger.
- It can initiate software projects, explore the hypothetical project scope and surrounding areas, and dramatically speed up the requirements-gathering phase.
- It can complement other formats, such as the Business Model Canvas, to help you envision new businesses by focusing on the future narrative, leveraging the “wisdom of the crowd,” and building a robust future hypothesis.
- You can use EventStorming at the beginning of an agile transformation, discovering all the conflicting perspectives around a shared process, typically spanning strategic planning to value delivery.
The list may continue. You can use variations of these formats to build sensible roadmaps and plans, structured storyboarding, and more.
The outcome
It’s easy to mistake the artefact for the actual workshop outcome. It’s big, colourful, and provides a reference shape for your business.

This is great, but the conversations needed to build the shared model are usually the most valuable outcome of the workshop. They dig into years and misunderstandings and across silo boundaries to provide clarity and confidence to key people in your organisation.
When you can finally observe your system as a cohesive whole, you enable change. People are afraid of breaking invisible things, and our relentless effort to make everything visible turns even the most intricate businesses into systems that can be improved.
Why is it relevant?
The larger the organisation, the harder it becomes to detect and solve problems, especially those without clear ownership. When teams are overburdened, they focus on their local scope, waiting for someone to address the systemic issues.
Acting on areas with unclear ownership requires clarity, coordination, and political consensus, and Big Picture EventStorming provides precisely that.
The format investigates the entire system while separating the key signal from the noise. It provides a detailed background for deeper analysis and issue resolution. Then, it leverages the presence of key decision-makers in the room to provide the political support and momentum needed to address the most critical issues.
Last but not least, it can be a perfect complement to strategic tools like Wardley Maps or Impact Mapping, ensuring the vision is aligned with current reality.
Process Modelling EventStorming
The Process Modelling format is an excellent tool for discovering the intricacies of complex business processes and designing new ones. It builds on the idea of collaborative games, providing your modelling team with a simple set of rules.
-
- Every path should be completed.
- The grammar must be respected.
- Every stakeholder should be reasonably happy.
- Every Hot Spot should be addressed.
Rule number one is the most straightforward: a process ends in a stable state, usually an Event that requires no further action.
The more peculiar rule concerns grammar. It’s been designed to force workshop participants to address challenging questions, and it usually requires a couple of interactions to become confident.

The EventStorming Process Modelling grammar applied to a conference call for papers scenario.
Rule number 3 – making the stakeholders reasonably happy – opens the door to business value and UX concerns, allowing your modelling team to balance mechanical steps for formal flow correctness with emotional ingredients like “how a given message impacts the user’s feelings.”
Finally, you can use Hot Spots to highlight critical areas. You can’t start with a perfect design. You’ll start with a plausible one instead. Then, you refine it incrementally, addressing the emerging concerns.
The result is a very enjoyable Collaborative Modelling experience, where different perspectives can blend into a design that addresses interdisciplinary concerns without falling into the trap of design by committee.
The outcome
The resulting artefact of a Process Modelling EventStorming is a low-fidelity, battle-tested process description that can be progressively enhanced to address trickier corner cases.

Once again, the journey matters. Every Hot Spot addressed during the discussion is the equivalent of a new revision of a more formally specified process.
Shared ownership and the consequential buy-in are interesting consequences of the Collaborative Modelling approach. Concerns are explicit from the beginning, and addressing them together provides more options for resolution.
Why is it relevant?
Complex business processes are rarely designed collaboratively; however, modern processes—especially those that are customer-facing—are a mix of formal robustness and user experience concerns.
One-sided design processes may require lengthy negotiations before approval, but they can’t avoid last-minute surprises. A collaboratively designed process may address blocking concerns from the inception phase, leading to a solution with embedded buy-in.
Process Modelling EventStorming is the ideal format for supporting a discussion that merges the different perspectives into a powerful co-designed artefact.
Doing it online?
The online experience has the obvious advantage of being more accessible to distributed teams, but it comes at a small cost in terms of effectiveness. We recommend trying the in-person version first to detect when workshop mechanics aren’t delivering as they should.
When running an online workshop, you may want to check our free template on Miro.
Software Design EventStorming
The Software Design EventStorming aims to design software models to support complex business processes. The Event-driven nature of the exploration makes it a perfect modelling tool for Domain-Driven Design, keeping the discussion in the liminal space between business and technology while supporting more software-oriented activities, such as determining boundaries between cooperating models (see also Context Mapping) and enforcing consistency across the Aggregates lifecycle.
Software Design EventStorming is still based on the idea of collaborative games, but expands the grammar with extra building blocks and extends the Process Modelling ruleset with two extra rules.
-
- Boundaries should be visualised.
- Software components should have consistent behaviour.
The expanded grammar allows boundaries to be visualised—and moved, in the case of discussions—bringing coherence to the picture.

The EventStorming Software Design Grammar
Boundaries will shift the discussion into the competing purposes of the stakeholders involved, providing a fantastic playground for Greenfield Context Mapping. Meanwhile, we can detect signals to define a semantically robust lifecycle for our emerging Aggregates.
We can include wireframe sketches in the discussion, especially if the page layout actively influences your users’ decisions.
A Software Design EventStorming session is also a great place to stress and distil your Ubiquitous Language, or to challenge your model with complex real-world scenarios that can be turned into acceptance tests.
The outcome
A Software Design EventStorming usually results in a left-to-right flow where boundaries and key building blocks start to emerge. Aggregates are shaped by their behaviour and role in the end-to-end interaction, looking more like state machines than data containers.
Green Read Models instead capture the data needed to make key decisions. The discussion also raises many issues we can capture with magenta Hot Spots.

Another significant outcome is likely in the trash can: ideas we tried and discarded, wordings that turned out naive after closer scrutiny, and Hot Spots we resolved in a previous iteration.
The model starts wrong and progressively evolves towards greatness, with everybody’s contribution progressively rewriting and rearranging the building blocks.
Why is it relevant?
Complex business processes are often a source of coupling inside enterprise software applications. Traditional requirements-gathering strategies too often fail to resolve inconsistencies when multiple stakeholders are involved.
Software Design EventStorming enforces coherence between the business and technical perspectives, leveraging domain events to build more precise narratives and effective implementation.
Events are a semantically more robust building block for describing the behaviour of complicated systems and enabling architectural opportunities such as Event-Driven Architecture or CQRS/ES.
Putting it all together
As a whole, EventStorming is an incredibly versatile tool. We can use it to investigate an intricate current state or envision a possible future.
We can embrace the unlimited modelling space metaphor and explore the system as a whole or focus on a specific business flow. The event-centred notation will allow coherence when zooming in and adding details.
EventStorming can support strategic business decisions and help you design better services and more effective and efficient software applications.
More than anything, it can enhance collaboration between people from diverse backgrounds, transforming design discussions into enjoyable experiences.
EventStorming is a key ingredient of Avanscoperta’s consulting services.
We also offer learning experiences such as the EventStorming Masterclass or the EventStorming Remote Experience.
You may want to check the resources and patterns available on our partner website EventStorming.com.