Event Storming, created by Alberto Brandolini, is a flexible workshop format for the collaborative exploration of complex business domains. It is by far the most effective method we have seen for understanding business processes, solving problems, and agreeing on priorities. It naturally engages stakeholders and helps create alignment between separate departments in an organization.
So what is a complex domain?
"A network of interdependent agents influencing each other" —Alberto Brandolini
In an organisation, a complex domain arises when tasks are being performed in multiple steps with multiple teams/people involved. An example could be recruitment process, where multiple stakeholders—HR, the hiring manager, team members, and security—must evaluate a candidate from different perspectives. The decision-making is collaborative, and success depends on factors like team fit, timing, communication, and adaptability. Even with clear goals, the outcome is not entirely predictable, and each hiring situation may require different approaches to achieve effective onboarding and long-term success.
When a domain is complex, the real challenge in software projects is not writing code faster—it's understanding the domain or business processes more quickly. It's about identifying the right problem to solve.
While we have many tools that help us write software faster, there are still very few that help us understand the domain more effectively. This is where Event Storming comes to our rescue.
Event Storming uses a building block called Domain Event. A Domain Event is something that happens that is relevant for a business or organisation.
Event Storming can be done on different levels and for different purposes. The three most common variations are:
At all levels Event Storming is based on Domain Events placed on a time line, but each level introduce new kinds of items to the notation:
The main purpose of Big Picture is to maximise learning by collaboratively exploring a business domain. We want to create a shared understanding across departments or silos and agree on which are the most critical problems to solve. During the workshop we will automatically visualise inconsistencies. Example scenarios include:
Domain Events are collected in mixed order through brainstorming but will eventually be arranged on a timeline. During the activity of arranging domain events on a timeline, participants need to communicate and will often discover things that they might not have thought of before. Interesting discussions arise. The participants’ different views are uncovered. If participants disagree at first - that is good, sometimes even preferable. Disagreement is better than silence. In Process Modelling and Software Design we often chose to build the timeline incrementally right from the start and skip the "chaotic" step where events are in mixed order.
Most commonly in Big Picture we use a notation with 5 different colors. It’s always the goal of the workshop that should decide which notation to use. There is no best practise notation that works in all situations. Feel free to customise it for your needs. Experience will help you make better and better choices. Sometimes we don’t use Actors and Systems at all. Sometimes we use Actors and Systems sparsely.
So you got asked to to facilitate a Big Picture Event Storming session need to prepare. Let’s look at the steps.
The room is ready and participants are in, it’s time to kick-off the workshop. Let’s look at an overview of the workshop steps and then look into some of the steps in more detail.
Start with a short informal presentation round. Possibly do a quick time-boxed (20 min) warm-up round on something everyone is familiar with like a recruitment process or ordering a pizza online. Present the goals and make sure there is some degree of alignment with the objectives. You might want to say something like: “We’re going to explore the business process as a whole by placing all the relevant events along a timeline. We’ll highlight ideas, risks, and opportunities along the way.” Do just a minimum of explanation of the method upfront. Rather expand on concepts along the way as needed. Keep a legend clearly visible on a separate white board and explain the notation before you begin.
Ask the participants now write domain events on orange sticky notes and place them on the wall all at the same time. Let each participant grab a bunch of orange sticky notes and a marker pen and encourage them to start writing domain events. It can be good to warn the participants that this phase will be chaotic and that’s okay. We’ll introduce more structure later. It’s more productive to get into the action as soon as possible. You might have to help them to get started by asking questions. General questions that are likely to work for most organisations could be: “Do you receive payments?” or “Are contracts being signed at some point?” You might have to walk over to someone that is hesitating and ask if they can think of any events that are relevant in their work and encourage them to write it down. Your job is to help everyone get into the flow. Usually it doesn’t take too long time. Conversations can pop up but this initial phase can also be quiet. People work in parallel. We usually timebox the chaotic exploration phase to around 30 minutes. Can be longer or shorter depending on the size of the scope. If there are missing events they will be added later. So no need to wait for every single invent to be written at this stage.
Here we "force" the participants to start collaborating for real by asking them to sort all events on a timeline left to right. Some participants may have created their own timeline on a separate space independent of the others, now they have to cooperate to get the timeline right. During this phase also encourage the participants to add missing events and also start adding Hotspots and Opportunities along the way.
Sometimes events might happen in any order and a participant may ask you which order to put them in. Answer: Were not looking for perfection here, It probably doesn’t matter. Just put them in the preferred order if there is one.
Arranging all the events on a single timeline is easier said than done. We can easily run out of space in some sections of the wall while other sections almost blank. After a few minutes of struggle you as facilitator will most likely need to step in and do the quite tricky task of figuring out which sorting strategy that you think will work best and help the participants apply it. Here are some useful sorting strategies:
Whenever there is a disagreement or a problem seems to be something we should revisit, encouraged the participants to write a red Hotspot sticky note and place where the problem is. This helps us to move forward and revisit all problems at the same time later.
Identify the most important events (pivotal events) and mark them with for example a yellow piece of tape placed under the event. Then ask the participants to make sure all other events are placed in the correct place in time related to the pivotal events. Don’t spend too much time trying to select the perfect pivotal events. The goal here is to spread out the events evenly on the workspace. Feel free to to change pivotal events as the structure emerges. Try looking events which are particularly relevant for the business and mark a transition between different business phases.
Use a pen to draw swimlanes on the surface to separate different roles or processes. The benefit of this strategy is that the result is easy to read and very visual. The downside is that it tend to occupy a lot of space.
We almost always end up using Pivotal Events at first and then we add local Swimlanes wherever it can help making the result more clear.
Which are the key roles and key system involved in our flow of events? In this step we’re making it visible. This can help us a lot in understanding the challenges we’re facing. This step can generate a huge amount of hotspots and comments. We use little yellow stickies for people, and large pink stickies for external systems. And we’ll place them on the modeling surface, wherever it is important to visualise that they play a role in the event flow. Sometimes this step is not needed. If you already are drowning in hotspots and opportunities. Or if the system doesn’t exist yet or is evident to every participant. Sometimes we only need to explicitly point out roles and systems where we are relying on third parties.
A great way to enforce consistency is to ask participants to take turns as narrators. Ask a participant to (literarily) walk along the timeline and talk us through the chain of events. It’s the job of the audience to challenge the narrative whenever it doesn’t make sense and help filling the gaps. Being narrator is quite hard so let the participants take turns (5 – 10 min each). Rearrange events when needed. Add missing events. Add hotspots and opportunities. Let the participants help the narrator to add missing sticky notes. This is the step that will make most time. It can easily take a few hours. Put in refreshment breaks.
When the Explicit Walkthrough is done. Make a final explicit walkthrough in reverse order. Begin from the end and move backwards to the start. For example: In order for an invoice to be payed it has to be sent. That means that the Domain Event "Invoice Sent" should appear somewhere to the left of "Invoice Paid". Here we usually find additional events. When we do, stop and ask the audience to help writing more sticky notes. In the end of this section, ask all the participants if there is something missing. Expect some more additions.
Let everyone in the room state which problems they experience and which opportunities they see. Although you might already have collected many hotspots and opportunities, now is the time to give everyone in the room a final chance to state their opinions about which additional problems they experience and which opportunities they see. Give the room for example 10-15 minutes to focus on only adding problems and opportunities. Use the hotspot color for problems and the more optimistic green for opportunities.
Many facilitator’s favorite part of Big Picture Event Storming. Give each participant 2-3 arrow votes. An arrow vote is a large black arrow drawn on a blue sticky note. Say for example: “Everything we have captured here today is important, but now you have the chance to select your two most urgent problems or opportunities that you think are the most important things to work on."
Only once everything is visible it make sense to choose the most important problem to solve. Sometimes you get a clear consensus. Sometimes you will be surprised. Regardless the end result should be visual. A good big picture event storming session is a massive learning experience crossing silo boundaries (many time domain experts end up learning more about their own organisation). We usually get a few problem/opportunities that are clear winners just from glancing at the wall.
Sometimes the end result has already been reached at the end of the session. Every participant has gained a deeper understanding of the domain in less than one day and the top problems/opportunities to act on has been identified. For most organisations, just agreeing on and solving (or taking advantage of) the top 2-3 problems (or opportunities) would probably mean a new higher level of performance. In some cases the only needed documentation is just the 2-3 top problems/opportunities (and you can get rid of everything else). Sometimes we want to make sure to document everything afterwards and continue with process modelling and software design the next day or week. Regardless we recommend that you take pictures so you can go back and revisit the result.
Process Modeling uses the same notation as Big Picture extended with the notation and colors shown here.
Process Modeling Notation
Example of the color grammar of the Process Modeling Notation.
This “color grammar” is the exact order that we repeat over and over again.
Event > Policy* > Command > System > Event
*) If the policy is requiring a human to take action, squeeze in a yellow human between the policy and the command and a green “Read Model” which represents the information the human is looking at to take the action.
This exact order is made to be compatible with the Software Design level of event storming. Sometimes the blue “Commands” feel like you just repeat the words from the corresponding event. It usually takes some time to get familiar with the system.
Sometimes we use a happy “smiley” to mark steps where we feel that we create value (for example we make our clients happy) and sad smiley where we destroy value (for example where we keep a client waiting for too long).
When facilitating a Process Modelling event storming session. Try using corporate game thinking: The participants are a team competing “against the problem”. If they manage to solve the problem, then they are winners. They win when:
Read Models Guide
A Read Model helps us specify the information needed in order to take a given decision.
Policies
Policies are the lilac/purple glue between an Event and the resulting action(s)
dealing with non-linear processes. For
Example a ‘Phone’ or a ‘Chatbot’
said.
condition of the conversation and treat
the process as a checklist.
Actions can also be called Commands
Software Design Event Storming
When using DDD approaches to design software, two of the most important things you’re looking for are Bounded Contexts and Aggregates.
This is easier said than done. One of the hardest problems (up until now) in complex software projects is to find a solid and sustainable way to split a system into subsystems and components.
Let’s start looking at Bounded Contexts and then Aggregates.
A key challenge in enterprise software projects is to slice the system into suitable independent pieces. The idea in DDD is to draw the dividing lines between systems along “cultural” borders in the company.
In the big picture event storming workshop you will likely see different groups of people using different terminologies (language) and behave differently. By observing the groups in the room you get the clues to how the system should be split. For example you might not want sales people to share system with accounting. Imagine the problems that could arise from being forced to make the sales team and the accounting department agree with each other for every system change.
Ideally, a bounded context should be a system tailored around a specific purpose: the perfectly shaped tool for one specific job.
During the ES session, whenever we see a distinct purpose emerging, we should consider the possibility that it’s a new bounded context, and if so, let it be a separate system/model and find the best way to allow it to interact with the other systems/models.
Software Design Event Storming is basically just an extension of Process Modelling Event Storming. You do all the same things as you did in Process Modelling but replace the pink System sticky notes with yellow Aggregates wherever you plan to build a system instead of using external system/black box. Leave any other Systems as they are.
At the end of a software design event storming, move out all the identified aggregates to a separate blank part of the board. When you find the same aggregate appearing in many places in the workflow, merge them together as one. Next collect all commands and events and place them before and after the Aggregate. Magically you’ve got components defined! :) Now you can likely see missing commands and events and complete the component to allow it to behave consistently.
Rules of the game
- Every path should be completed
- Colour grammar must be respected
- Every stakeholder should be reasonably happy
- Every Hotspot must be addressed
- Every component should have consistent behaviour
- Bounded contexts should be visible
Our pink System has just been replaced with a light yellow Aggregate. Sometimes we keep both the pink system and the yellow aggregate visible side-by-side when we are designing an adapter to a black box system.
Introducing Event Storming by Alberto Brandolini (original blog post)
Introducing Event Storming by Alberto Brandolini (Leanpub book)
