I’ve very recently passed a personal milestone in my career. I facilitated my first ever event storm. As with most things you haven’t done before, doing them the first time is a good opportunity to learn.

In preparation, I was reading as much as I could on event storming and how to facilitate it. However, there was one big pitfall. Event storming is a workshop format designed for real-life collaboration, not virtual collaboration. It’s designed to have many discussions going on in parallel and to be very organic. In times of remote work, this is an extra challenge that has to be overcome.

What is event storming?

For those who don’t know (or don’t remember) what event storming is, here’s a quick recap. The name event storming comes from combining “event” and “brain storming”. It’s a domain exploring and modelling technique, based on domain events. There are many forms of event storming, but the base idea in each of them is to gather a diverse group of people who know the domain and create a timeline of domain events using sticky notes.

While creating this timeline, discussions will occur about parts of the timeline, because things are unclear or because people disagree. The process of creating the timeline and discussing makes sure the group ends up with a shared understanding of the domain and a visual representation of this understanding. If you want to learn more, head over to the event storming website.

The learnings: organising a remote event storm

The workshop itself went pretty well. There was enough interaction and the end result was good. The feedback we received was mainly positive and some people even asked for more in-depth event storms to go into more detail.

But it was not perfect. Below are some things I think went well and some things I think could be improved.

Keep groups small

Keeping participants engaged during the workshop is very important. When a discussion happens in a large group, some people will zone out or start doing other things. Once that happens, you’ve basically lost them. When the group is smaller, it’s easier to keep everyone involved by asking for input every now and then.

Nine people attended the workshop. We split this up into two groups of 4 and 5 participants. Both groups did their own event storm. When the time for the workshops was over, we gathered again and each group presented their result.

It was surprising to see how different the result was in format. I think next time, both groups should be more aligned on the format of the workshop, so the end results can be compared more easily.

Keep discussions short

As with everything where multiple people are at the same place, some people will disagree with each other. This disagreement is very important during event storming because it points out where the domain is unclear. But nothing is as boring as watching 2 people argue over a tiny detail you don’t really care about.

In a physical event storm, you would probably go to another part of the wall with sticky notes and start arranging something there, or start a discussion with someone else. In a virtual event storm, you’re stuck.

As a facilitator, it’s important to not let these discussions go on for too long. If the participants come to an agreement quickly, it’s fine. If they don’t, mark the unclear spot on the timeline with a special sticky note. If needed, you can come back to it later, maybe with different participants.

Make sure everyone knows the tools

We used Miro for card creation during the event storm. Unfortunately, not every participant had used Miro before or even had an account. While making an account was not a big hassle, it still meant that those participants missed part of the introduction.

When the actual workshop started, they still had to figure out how Miro works. Luckily it was only adding and moving stickies around, but getting to know the tool is still a small bridge to cross before you can focus on the actual workshop.

Cruddy parts of the domain

The domain we were mapping is the domain already covered by the existing software. Some parts of that software are particularly cruddy (create, read, update, delete), yet they are important to the overall flow. We lost quite a lot of time trying to agree on a timeline for that part of the software.

Only after a while did it occur that nothing really interesting happens there in the domain, except entering data in the system. Next time I should try to skip those parts or be more aware of their cruddy nature and stop the discussions faster.

Timing the initial event storm

My initial plan was to do a very short event storm at first. It shouldn’t go too much into detail and would mainly serve the purpose of identifying larger parts where we could go more in depth.

This would help to keep the flow of the workshop going and help in keeping the participants focused (or give them natural points in time to regain focus and catch up with the group again). So I timed an initial event storm for 10 minutes. Turns out you can think of a lot of domain events when you have 10 minutes.

We gathered enough events to fill the rest of the workshop with creating a timeline and discussing. I don’t think it influenced the outcome too much, but it made the workshop into 1 long session instead of many smaller sessions, as I originally intended. Next time, I’ll make it 1 minute and add some extra time if needed.

Timing of the workshop

We agreed on approximately 2 hours for the workshop. Before the workshop, I was scared this would not be enough time. After the workshop, I was glad we timeboxed it to 2 hours. I was exhausted.

Discussions online consume way more energy than discussions in person. Take that into account and plan accordingly. Doing a workshop on a Friday afternoon doesn’t help with the energy level either 😏.

On to the next event storm

I know these learnings will help me when facilitating my next event storm. Hopefully, they can be useful for you too. Let us know if you learned any specific tips or tricks you apply.