Event Storming at a Glance

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.

Person is writing on coloured sticky notes
peoplecreations on Freepik

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.

bunte Zettel mit Pfeilen verbunden
Figure 1: First original order of Event Storming artifacts defined by Alberto Brandolini

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.

viele bunte Zettel, die in Beziehung zueinander stehen, durch Pfeile verbunden sind
Figure 2: An example of the end result that was created during a four-hour storming session

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)

This post was written by:

Hendrik Loesch

Hendrik Lösch is a consultant and architect of ZEISS Digital Innovation. He focuses on the development and evaluation of software based on Microsoft technologies. In addition, he likes to write and talk about his work and his enthusiasm for clean code, software evolution and test automation in their various forms.

See author's posts