A practical guide how to run a project kickoff using Event Storming

Katarzyna Kurzynska

September 5, 2018

Night mode

We were sitting in the conference room preparing for project kickoff.

"Ok, the client is coming to our office tomorrow. They want to launch the app in 7 weeks, so the deadline is quite tight. Also, this is probably going to be the last time we have a chance to talk to them face to face. We really need to focus and write down all the things we need to discuss."

So we got to work. While going through the whole flow we were writing down all the things that need to be discussed. At some point, my mind started drifting off. It was a long and arduous process. And the meeting with a client wasn't going to be any better... But then an idea popped into my mind:

"Hey, folks, have you heard of event storming?"

Ok, it is not entirely what happened.

But it might have! We all know how meetings can be tedious. We all know how easy it is to forget or just miss something. Especially when the system is to be complicated. During our last project kickoff, we decided to address those problems using event storming. And now we would like to share the lesson.

So, what is this event storming?

‍

Event Storming is a technique coming from Domain Driven Development word, which has been developed by Alberto Brandolini. Its aim is to get the developers and the business stakeholders in a room and visualize the business processes. To trigger conversations. To make sure that everybody is on the same page. To ask questions and get answers.

Sounds great, doesn't it?

We used a bit modified version of Event Storming. Let's go through the whole process.

What do you need?

First you need the right people. In theory, you would like to have participants coming from two fields: people with questions (people that are going to develop the product) and people with answers (people knowing the business context). In practice, you want all the people who are going to work on the project, domain experts, managers, clients to take part in the workshop.
Time: the process probably is going to take few hours.
A facilitator
Proper room: do not want to be interrupted nor disturbed during the process.
Unlimited modeling space. The thing is that often complex problems are not properly analyzed because there’s not enough space available to see the problem. We used one of the walls in our office covered with flipchart's cards.
Huge stack of sticky notes
Working marker for each participant of the group

The steps (our way):

Gather everybody in front of modeling space. Make sure that everybody is standing up. The thing is that people just get lazy when they sit. Probably it would be a good idea just to hide the chairs.
Explain the whole process: the facilitator should make sure that everybody knows the rules of the game.
Produce stickies with all domain events occurring in our business context and put them on our timeline represented by our wall.
Ok, wait a minute. Just what is a domain event?
It is something meaningful what happens in our domain context. For example, if you are modeling a voice system for managing the light in a smart house the events might be:
The user requested turning on the light
A light bulb burned.

‍

The event should be written in past tense. Why? The rule comes from the origins of the method, where the events are translated to the software events. In our case, it did not provide us with much value. However, it is a good idea to have some convention.
Also, the facilitator should put the first stickie to show how it works.
Go from the end of the timeline and check if for each card everything "has happened" to make this event possible. During that, we also want to organize the cards in the way, that each card is in its context.
Put all externals systems on the wall in the context that they belong to. Use a different color of cards.
For each system discuss how you want to handle its failure
Run a thought experiment: the half of the team is hit by a car. We cannot implement the whole system in time. What are the core events that we would implement? Mark them with an exclamation mark.
Ask the questions relevant for your context:
Which events correspond to the thesis you want to validate?
Where the money lay in the system?
Mark the relevant events with a star.

During this process, a lot of questions are going to be asked. Most of them are going to be answered, but some are not. You want to write down those questions down / mark the relevant stickies with a question mark.

Ok, sounds like fun, just what this method actually gives us?

This method makes the team go through the whole flow of the application/system. It forces discussions. The system is visualized so it minimizes a risk that something is going to be misunderstood.
Also, when somebody wants to discuss some problem related to a certain part of the system then she/he might just point to the relevant card. This way, we can make sure that everybody knows what the question is related to.

However, we discovered that there are some traps in the way that you need to be careful about:

People get tired. In order to avoid that remember to schedule the breaks before starting.
After the workshop, there may be some questions that need to be answered. You want to get those answers as soon as possible. Firstly those questions might be blockers for you. Secondly, after some time the memories will blur and the client/business people might forget what the question really was about. Or even better it might inspire her/him to add new features. It might be unwanted, especially when you have to meet a tight deadline.
Clients/business people might be skeptical about the technique and it might be a good idea to give them a brief introduction/some resources before the workshop.
Also, at some point an inexperienced facilitator might come across some problem, that makes her/him confused. It might be a good idea to run a workshop with a team on some small, easy example before the workshop. For a sake of practice.

And... that's it. Hope that you find that information useful.

If you would like to read more about the event storming take a look at the following:
http://eventstorming.com/
http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html
https://blog.redelastic.com/corporate-arts-crafts-modelling-reactive-systems-with-event-storming-73c6236f5dd7
http://verraes.net/2013/08/facilitating-event-storming/
http://ziobrando.blogspot.com/search/label/EventStorming

‍

Back to blog