If you think event storming involves boarding up the windows, grabbing a few lanterns, and busting out the emergency Twinkies, it’s time to read on. 

Event storming is an efficient way of gathering your team together to dig into a complicated process and model. Based on that visual representation of your process, you can deliver next steps and work toward delivering better value to your customers.

Below we’ll cover what event storming is and the steps you should follow for a successful event storming session.

What is event storming?

EventStorming is a flexible workshop that takes a rapid group modeling approach to design. Event storming was created in 2012 by Alberto Branolini, who believes that “problems cannot be solved with the same mindset that originated them.” Alberto has been coding since 1982 and has been invested in domain-driven design (DDD) since 2005. 

Alberto’s idea for event storming emerged from Gamestorming, a Silicon Valley-based way for teams to innovate through the use of a game that guides them to a particular goal. Gamestorming relies on lots of sticky notes, butcher paper, markers, and diagrams.

Similarly, event storming uses the same materials to guide a group to a goal. The difference, however, is that event storming revolves less around creativity and more around pinpointing what’s happening inside the domain of a software program. 

There are a few key terms you’ll need to understand before we dive into event storming further:

Domain: A targeted subject area of a computer program

Domain event: Anything that happens on the domain that a domain expert would care about

Domain expert: Someone with a deep understanding of the business’ products, programs, or offerings

Event storming is an efficient way to harness the power of group learning to understand the complexities of a domain. And that’s important because it’s rare that all team members have a common understanding of the domain. Usually, domain knowledge is understood differently by architects, test users, etc., which means it’s difficult to define the complete domain model your developers need.

While event storming utilizes DDD (domain-driven design) events and other concepts, it’s not the same thing as DDD. In traditional DDD, small groups or individual developers have cursory conversations with the product owner and then begin modeling. But that doesn’t look at modeling confined to the business domain and it also requires everyone involved to be trained in DDD. 

Event storming looks at modeling strictly through domain events. Examining these domain events forces everyone to use the same language when discussing the domain. Events are currently happening, so it’s a pragmatic look at the domain instead of relying on hypothetical situations. 

When you should use event storming:

• Before beginning a project
• After a project has been completed
• Before implementing a new feature
• Before beginning a new story
• To find an alternative to a current process

8 steps of the event storming process

Follow the event storming steps below to lead a successful event storming session:

Step 1: Gather your team

The first step to running an event storming workshop is to invite the right people and gather them together. A facilitator will typically give an overview of how the workshop will proceed and will also provide a list of common terms that are helpful to know for the event storming workshop. 

In addition to common terms, your facilitator should also provide a key explaining what each color of sticky note represents:

Orange = Events. As the most important part of your event storming workshop, you should plan to have plenty of orange sticky notes. Events are in past tense.

Blue = Commands. These are requests from a user, system, or another event.

Pink = System. These represent systems that issue or receive commands within the domain.

Yellow = User. To remind your team of the human element represented by this sticky note, you may wish to draw a stick figure here. The user can be one person or several people who trigger an event.

Tan = Aggregate. This is the platform on which the group of events operates. When a cluster of events can be clustered together, they’re termed an aggregate.

Grey = Policy. These are rules that may have to be executed, such as for compliance or authorization.

Step 2: Roll out

Event storming is a highly collaborative exercise, and no one gets to sit out. Use butcher paper to transform the walls of the room into writing surfaces. 

Pro tip: It’s much easier to use a virtual whiteboard like Lucidspark for event storming sessions, as it can be easily saved and shared.

Step 3: Storm your events

Since events are...well, the main event here, the first thing the team will do will be to brainstorm all events involved in the process. This step runs much like a brainstorm. Keep one event per sticky note and don’t worry about duplicates or events that are out of order. 

Step 4: Organize your events

Next, arrange your events in chronological order, discarding any duplicated events. Once your events are arranged sequentially, you’ll also be able to see if you’ve missed any events.

Step 5: Continue the model

Now it’s time to put the events in context. You’ll need to ask questions, such as:

• Who triggered this event? (User)
• What command is given? (Command)
• Which system is this event part of? (System)

For instance, if you’re modeling an ecommerce payment system, you may model a user shopping, adding an item to the cart, editing items in the cart, inputting payment, checking out, and receiving an order confirmation email.

Step 6: Group together

Clusters of events are aggregates. Indicate the aggregates on which events operate by adding in tan sticky notes.

Then, circle larger contexts within your model. Everything related to the shopping cart can be circled within the “shopping cart” context. The same could hold true for checkout.

Step 7: Find your microservices

Aggregates within your circles represent microservices. Make a notation of these within your event storming workshop. You might also choose to add capabilities so your architects and engineers can have a better idea of what they’ll need to build their target state.

Step 8: Next steps

Finally, when your model is complete, you’ll need to analyze the model and determine what your next steps should be. Then, assign those steps to members of your team.

Pros of event storming

Here are some of the great advantages to using event storming:

1. It relies on standardized vocabulary, so everyone invited can understand the domain.
2. It’s fast.
3. It’s highly collaborative and generates great conversations.
4. It’s fun!
5. It’s effective.
6. No one needs to be a DDD expert to participate.
7. Event storming can be applied to technical and business domains.
8. It can be used for complex domains or for small ones.
9. Event storming workshops bring disparate groups of people together for one common. goal, and that improves team building and camaraderie. 

Cons of event storming

1. If you’re conducting an in-person event storming session, it’s very easy for the sticky notes to get out of control and for the butcher paper to be misplaced. Again, this is where a virtual whiteboard comes in handy!
2. There’s a learning curve for those who are new to the event storming process
3. You may begin the event storming workshop and realize you’re missing a person or people who are key to the success of the workshop

As indicated, the pros of the event storming process far outweigh the cons. Even if your first event storming workshop doesn’t go as smoothly as you would have hoped, keep repeating the process, and you’ll find it only gets better with practice.