Event storming is fun! Running a successful workshop requires preparation and understanding of the Event Storming process.
Every workshop has an Event Storming Master (aka Facilitator or Moderator) to guide participants through the workshop.
The person taking on the role of Event Storming Master does not need to be the project Scrum Master or Technical Lead - as long as they know and understand the Event Storming concepts and discovery steps then they can run the workshop.
Before a workshop, the Event Storming Master is responsible for preparing the Event Storming workshop session, which will include:
It is important to invite the right people to the workshop. It is a problem if you're missing key participants or having too many participants.
Depending on the size and complexity of the project you would typically need between 2 to 4 hours for a good Event Storming workshop session.
During a Specification Review you can schedule this workshop on the first day. Typically on the second day you can use the Event Storming visuals to help design your system and software architecture and produce better estimates.
During a workshop, the Event Storming Master is responsible for helping participants to:
It is important to make sure that the common terms are recorded and clearly visible during the workshop.
Finally, make sure that the legend (explaining all the key concepts of Event Storming) is clearly visible.
Real-time collaboration (remote or in-person) has become the default choice for many teams. Instead of sticky notes and white-boards we can use tools such as:
These tools will eliminate the worry of low-quality sticky notes falling off the white-board and your markers drying up!
For remote sessions, collaboration might not be as smooth as the in person events. However, it is also easier to arrange the attendees to join a remote session when the team is not all in a single location.
You can break the workshop down into a number of distinct discovery steps. Each step adds more detail to the business domain or process you are trying to understand.
Use the <svg width="1.4em" height="1em" style="display: inline-block;"><rect width="1em" height="1em" rx="0.15em" ry="0.15em" x="0.2rem" y="0em" style="fill:rgb(255,102,0);" /></svg> orange sticky notes for Domain Events.
The domain experts and stakeholders can simply start recording the events that occur in a business domain or process. The events don't necessarily need to be in a precise timeline order (yet).
Domain events are always rooted in the past tense to represent a fact. Facts cannot be changed because they actually happened.
For example, we can have domain events such as 'Invoice Created', 'Email sent', 'Timesheet Updated'.
It can be expected that not all the participants will be aligned with the business domain or process at the start, but as the workshop progresses everyone will start to "get into the zone" and ideas will be put onto the board quickly and smoothly.
When there are concerns or contention, the participants can discuss and rearrange the events until it is resolved and everyone is aligned in their thinking. Sometimes the contention is due to a different terminology, so it is important to record the common terms and make sure that they are clearly visible to all participants.
The Event Storming Master should check the stickies to ensure that the basic rules are being followed (such as ensuring events are in the past tense), but instead of just correcting the stickies directly, they can be marked or rotated to be corrected at the end of the step. The Event Storming Master should not interrupt the participants while they are putting events on the board.
Use the <svg width="1.4em" height="1em" style="display: inline-block;"><rect width="1em" height="1em" rx="0.15em" ry="0.15em" x="0.2rem" y="0em" style="fill:rgb(255,0,0);" /></svg> red sticky notes on corresponding domain events when a concern or question is raised.
This will make it clear to participants that not everyone is aligned and will prompt further discussions until everyone is aligned.
Use the <svg width="1.4em" height="1em" style="display: inline-block;"><rect width="1em" height="1em" rx="0.15em" ry="0.15em" x="0.2rem" y="0em" style="fill:rgb(0,51,255);" /></svg> blue sticky notes for Commands (also known as Actions).
Use the light <svg width="1.4em" height="1em" style="display: inline-block;"><rect width="1em" height="1em" rx="0.15em" ry="0.15em" x="0.2rem" y="0em" style="fill:rgb(255,255,153);" /></svg> yellow sticky notes for Users / Actors / Personas.
Commands are the result of a User making a decisions and executing an operation.
In this step we dive into the Mechanics and Core components of the domain. The discussions about commands and actions will prompt us to ask questions such as "Why does user X need to perform a particular command?"
Once the events ordered chronologically we can start seeing a flow emerge.
Use <svg width="1.4em" height="1em" style="display: inline-block;"><rect width="1em" height="1em" rx="0.15em" ry="0.15em" x="0.2rem" y="0em" style="fill:rgb(0,153,0);" /></svg> green sticky notes for the Read Model data sources / projections.
Read Model shows the data that a User needs data to make a decision.
At this point you should be able to start building up the Aggregates (entities).
Use <svg width="1.4em" height="1em" style="display: inline-block;"><rect width="1em" height="1em" rx="0.15em" ry="0.15em" x="0.2rem" y="0em" style="fill:rgb(102,0,153);" /></svg> purple sticky notes for External Systems or Dependencies.
External Systems represents parts of the business domain or process outside of our control such as:
We expect external systems to respond to our Commands and/or Queries.
Use <svg width="1.4em" height="1em" style="display: inline-block;"><rect width="1em" height="1em" rx="0.15em" ry="0.15em" x="0.3rem" y="0em" style="fill:rgb(255,0,148);" /></svg> pink for Policies (aka Reactions).
Policies are the glue between the <svg width="1.4em" height="1em" style="display: inline-block;"><rect width="1em" height="1em" rx="0.15em" ry="0.15em" x="0.2rem" y="0em" style="fill:rgb(0,51,255);" /></svg> Commands and <svg width="1.4em" height="1em" style="display: inline-block;"><rect width="1em" height="1em" rx="0.15em" ry="0.15em" x="0.2rem" y="0em" style="fill:rgb(255,102,0);" /></svg> Events.
Policies are considered the reactive logic that represents the rules of a business domain or process. This reactive logic allows or denies the target event to be triggered.
Always spoken in terms of 'When-X Then-Y' or 'Whenever'.
For example:
Lots of sticky notes arranged chronologically that shows:
If you ran an in-person workshop using sticky notes and a white-board you should capture the end-to-end flow by taking a photograph or by digitizing it with one of the diagraming tool listed in Preparation - Choosing the right visualization tool.
Make sure that he flow is stored in a central repository where everyone can access it.
Having access to this visual flow will: