Daily routine in an EventStorming context

Zsofia Herendi
7 min readSep 13, 2020

Continuing a previous post where we looked at workflow diagramming alongside my daily routine, now I would like to show you how this would look like from an Event Storming perspective. As I get many questions around EventStorming being a workflow modeling. Well, yes and no. Let’s see the differences!

What is EventStorming?

A flexible workshop format for collaborative exploration of (complex) business domains. Most important thing is to visualize, because according to Alberto Brandolini (the inventor of EventStorming) you will only be able to do something with the mess. You cannot argue on something what you cannot see. So true, right?

I attended a master class on EventStorming in Milan back in 2018, you can read more about that in one of my previous posts.

The goal of each EventStorming session is to develop shared understanding. In a nutshell you gather relevant people in a room where there is a huge modeling space (preferably) on the wall and start capturing domain events and put those on a timeline so you can tell the domain story. And you as a group are discussing each and every post-it that makes it to the wall.

One domain event is on one post-it (usually on an orange one but the main thing here is being consistent with the colors). The domain event is a verb at past tense, and is something that is relevant for the domain expert. Past tense is important because this is how you tell a story. And yes, you need to be able to tell your domain’s story at the end.

It is not like turning everything we say into past tense!

You have read about EventStorming and you might know already that in an EventStorming workshop we map out domain events, the ones that domain experts care about. We write one event on one post-it and it is a verb at past tense.

One of my facilitator partner (I miss pre-covid times with in person workshops so much!!!), János Magyar used to introduce EventStorming with a classic old-school (but very effective!) way: he worked with physical materials so he handed out rubber stamps to a few people who needed to sit next to each other, and he handed over a piece of paper to the first attendee in the row who needed to pass the paper over to the next person. According to their roles in a basic procure flow these attendees also needed to stamp the paper using stamps like “ordered”, “verified”, “accounted”, “invoice issued”, “payment made”, “handed over”, etc.

This is the “contract” attendees needed to pass on and stamp in every stage (as per the onboarding to events activity). This contract contains only fake data.

The main thing here is for attendees to “feel” what it means to stamp something and understand the fact that it happened. And later when we were working with events and did the domain modeling, we could refer back to those stamps all the time. If you struggle with the events just think of the question: What would the stamp say?

So..verb at past tense…Many times I saw people struggling with this and usually what they do is writing the workflow steps and rephrasing it to be past tense. But this is much more than that if you look behind the scenes…

Let’s pick an example from my previous post: taking the dog for a walk. This is part of my daily routine (that’s why it is there). In the workflow diagram you can see that there is an activity for it: “take the dog for a walk”.

If my daily routine is the domain, then this is definitely something that the domain expert should care about. So let’s pretend we are on an EventStorming workshop now and we want to capture the event for this:

Referring to my above question, what would the stamp say here? Walk taken? Dog taken for a walk? Hm.. I would say stamp could be like walk started (and then we might need a walk finished event too):

With this mindset a part of my daily routine would look like this with events:

This is useful because I see the events and the timeliness of those. If your goal is to have a big picture EventStorming and to be able to tell the domain story this is more or less ok. But we can do much more than that with EventStorming!

Adding more details to increase engagement

You can incrementally add notations to increase detailedness of your model. We use the following notations in EventStorming (it is not important to use the same colors as below but to use colors consistently):

Notations (and color pattern) in EventStorming

If your facilitator is aware with EventStorming technique and knows the notations and has experience in using those, they can add any of these on the fly as you are having the conversations. For instance if I would tell you about my daily routine and I’m telling that I take my dog for a walk and if it is a rainy day I take him to close streets but if that is a sunny day I take him to the forest, you can immediately capture all these information:

And you can see that the actor is “dog owner” and not “me” or “Zsófi” or anything like this. If we look at the big picture event storming above and add the actors to it it would be something like this:

Even though the same person performs these it is recommended to name the actors according to their roles in the domain. Think of it how much easier is assigning skills to these roles later on when you are working for instance on the bounded contexts…

It shouldn’t be like this:

This would show that everything is done by Zsofi.

So with this mindset I added more details to my daily routine:

Building on the top of it — adding your own topping

Alberto always says that EventStorming is the pizza, you can add your own topping on it. According to my experiences what works really well with an EventStorming basis is User Story Mapping. I plan to write a separate article on this. So stay tuned.

On the other hand every tool has its blind spot and EventStorming’s is that you cannot see the different scenarios and examples. Otherwise — sticking to my daily routine example — how would I know what happens when coffee machine has no water in it or how do I know what kind of food to give to the dog? Or in which bag to collect the coffee capsules? All these could be important highlights in my domain.

You can very effectively apply Example Mapping together with your EventStorming model as you already have a domain story and the story will have rules. And from there you can apply the BDD mindset and break down the scenarios and the different examples. I believe you can learn the most about the technique from Kenny Baas-Schwegler, he gave quite a few talks about the topic.

I also applied example mapping when I looked at the different scenarios in my daily routine (rules are represented with dark blue post-it and the examples with dark green):

These are the different examples regarding the dog feeding context. Ups sorry…Rushed ahead with contexts. Anyway I’ll continue crunching that in another blog post :)
These are the different examples regarding the coffee making context.
Still coffee making context…Examples in terms of throwing away the used capsules…
Examples in the walking context.
Examples in the working context.

As a result I have a part of my daily routine “eventstormed” and extended with the different notations and rules and examples are added to it.

I hope I could give you an insight to Event Storming with this very simple literally daily example.

Stay tuned, I’m gonna write about context mapping of the above next time… :) Or if you cannot wait for it, in the meanwhile you can check out one of my previous blog posts about similar topic: How a relaxing coffee turned into strategic modeling…

--

--

Zsofia Herendi

I'm a product manager who always looks at how to make things better. I'm a Domain-driven Design enthusiast and have an addiction to optimize workflows.