In this blogpost, we are aiming to provide a short overview about Event Storming to clarify what it is, as well as why and when it should (or should not) be used.
What is Event Storming?
Event Storming is a workshop technique first popularized by Alberto Brandolini in 2013. It is an aid to enable technical and implementation experts to discuss the domain to be mapped and thereby reveal important domain objects and their interactions. The exact procedure depends very much on the actual goal of the workshop and the moderator.
The first step in an Event Storming session is to determine the domain events that occur and to put them into a chronological sequence. Next, the commands are identified that trigger the events, then the functional aggregation points, external systems, possible user interfaces, and global policies. This almost automatically results in a component and system overview as well as a common glossary.
Even if the result of an Event Storming session is itself some kind of documentation of the processes, this documentation is not suitable as such in the long run. The actual added value results from the discussions between the involved stakeholders and the basis for a comprehensive description of the activities which should then be written separately, e.g., as component and/or activity diagrams with supplementary explanations.
This becomes even clearer when you consider that Event Storming usually involves sticky notes and face-to-face meetings rather than remote sessions using tools such as the Miro board, as shown in the examples. It is however important to note that such tools can also help to bring different stakeholders together, as they ultimately lower the barrier to entry for all involved.
When to use Event Storming:
- Knowledge sharing between multiple professionals and stakeholders
- For existing software that is to be restructured
- Identification and documentation of complex workflows
When it may be better not to use Event Storming:
- If there is no option for all participants to spend two to four hours in a workshop
- When few or no requirements are known
- For simple design tasks
- If participants have a low technical background (then domain storytelling is more appropriate)