A few days ago, some colleagues at work ran a few Event Storming sessions, and I’d like to collect some tips that helped them make the sessions more productive and get past certain mental blocks. I’ll also add a few that I didn’t give them at the time but that I think may be useful ;)

First things first: what is Event Storming?

For anyone who doesn’t know this kind of session, we could sum it up as a very flexible kind of workshop that makes it easy to explore/discover/visualize complex aspects of the business. It’s a very versatile format that can be used in many contexts, but I don’t want to go deep into that in this post.

Since talking about Event Storming could fill a whole bunch of posts, for now I’ll settle for linking to the official website and a couple of interesting videos, and you can pull the thread from there.

The format is at our service

One of the most important things is to accept that Event Storming isn’t a rigid format. We need to be very clear that the format is at our service and that adapting it will help us reach our goals.

Its creator, Alberto Brandolini, says Event Storming is like a pizza, where we’re free to add our own toppings.

And, just to be clear, I have no problem with pineapple or broccoli pizza. Imagine what I might put on an Event Storming ;)

“We find it hard to think in events”

At first glance, this statement might look like a problem for a session with the word “event” in its name, but nothing could be further from the truth.

When people start using this format in domain discovery sessions, sometimes there’s a certain block caused by a kind of analysis paralysis. This is usually because technical people associate the orange sticky notes with events that will have to be published. It’s normal to make this association, because I think 99% of what’s been written about Event Storming refers to the orange sticky notes as “domain events”.

Let’s remember that we’re talking about a moment when we’re discovering the domain. It’s a pretty malleable moment, where divergent thinking comes first, and trying to map the orange sticky notes directly to events that will be published adds exactly the kind of rigidity that will get in the way of the session.

In these cases, my advice is to try to get the concept of “domain event” out of our heads and think about “relevant things that have happened at the business level”.

Also, if we think about the business people who’ll be in the session, which concept will be easier for them to understand? Which one carries more technical baggage? In a session where the goal is to talk about the business, the fewer connotations from the world of technical design we bring in, the better.

Of course, the same applies to commands. Not every command will end up being reflected as such in the system.

We should focus on the ubiquitous language

If there’s an ideal moment to define the ubiquitous language, it’s precisely a session where we bring together the people who have the business knowledge and the people who are going to turn it into code.

This is an opportunity we shouldn’t waste, especially because in these sessions something happens that, although it seems obvious, doesn’t always happen: people from different teams or departments of the business side talk about the same business area, not to mention the technical side.

“But aren’t we applying DDD?”

It’s true that this format is strongly associated with DDD and that there’s a lot of material online about how to use it to discover aggregates, bounded contexts, etc.

We can certainly use it for that, but this format has a lot to offer even if we’re not applying DDD or aren’t at that point of the discovery phase. That’s fine; let’s remember that the format is at our service.

You have to get the hang of it

Like everything, this kind of format takes some practice to facilitate smoothly. So my advice is to practice it several times first in “safe” spaces, with few people, preferably from the same team, without involving business people. Something like doing a code kata, but applied to practicing Event Storming.

Another thing that helps a lot is for the facilitator not to be an active participant in the session. An interesting option is to have someone from another team facilitate it. That way that person can focus 100% on their mission: keeping the flow going, stopping anyone from monopolizing the conversation and, in general, supporting the discovery process.

In short

This is a very versatile format that can help us a lot in discovery processes or in sharing business knowledge and, above all, we shouldn’t worry if it’s a bit hard at first. Like everything, it gets better with practice!

Alberto Brandolini - 100,000 Orange Stickies Later | Øredev 2019
Alberto Brandolini — The Precision Blade
Header photo