Were you faced with implementing a new complex feature, just to discover edge case after edge case? Or did you work on a specific component, without understanding how the changes impact the overall system?
In this article, you will discover a technique that will prevent headaches and frustration when dealing with hidden dependencies, complexity or unclear requirements.
Alberto Brandolini invented Event Storming to align people in a common understanding of the business procedures, user flows, and the value creation process.
Before starting any implementation, we expect that requirements are given by domain experts (product owners, business analysts, game designers, etc).
The fundamental assumption that this technique challenges is that a single person knows the whole business domain.
That might be true in certain companies or smaller businesses, however, the reality is that we are dealing with knowledge silos and complex system, where the so-called domain experts know a certain part of the big picture and not all dependencies.
The goal of the event storming technique is to create a shared understanding of the value creation flow. Key stakeholders must participate, be in the same room and map out all domain events that are part of the system. Only through collaborative work, weaknesses are discovered and can be acted upon.
I used this method for improving our continuous delivery process. I used it in aligning understanding of our assets pipeline. When I was part of a cross-functional team, I used it before starting to implement bigger features to reduce risks and discovering all the possible flows that can influence the user flow. Over and over it brought the results that we expected and it saved many hours of building the wrong thing.
So let’s take a look at the actual steps involved in organizing an Event Storming session.
Step 1. Schedule a workshop and invite the right people.
You will need a mix of people who can ask questions (usually developers, qa engineers) and people who can answer them (usually the domain experts). The number of participants should be at least 4 persons but not more than 8, otherwise, the logistics and moderation effort would be too high.
You need a dedicated moderator as he will have a key role in the workshop. Bring posits with various colors (especially orange ones) Bring a long big plotter paper that you tape onto the entire length of the main wall. Push all chairs and tables to the corner as the workshop will be quite interactive and you need all participants to be engaged as much as possible. Draw an arrow from left to right on the plotter paper, reprising a timeline.
The room should look something like this:
Step 2. Ask the participants to write down the key events in their domain as an orange sticky note, in a verb at past tense and to place them along the timeline.
This phase marks the start of modeling the whole business line with domain events. Most participants might be a bit confused at start, but as the first event is added to the board, people start getting in a state of flow.
The moderator should keep an eye on all inserted stickers. If there are some that don’t follow the rules (e.g. not a verb at past tense) he should not interrupt the process but rotate a bit the sticker to mark that something is not right.
Some participants will make remarks on certain events, like this is always causing trouble, or I have no idea what is going on here. The moderator should capture these warnings on a purple sticker and place them close to the corresponding events.
Constraints, issues or ambiguities will be soon exposed. Key terms definitions should be captured by the moderator on a special yellow stick note and placed below the normal flow. This will help build a terminology that is commonly understood.
After this phase, your wall should look something like this.
Step 3. Start getting deeper into the mechanics and core components of the domain.
After having all the events visualized and ordered chronologically start adding blue stickers that represent user actions/intentions/decisions. For example: “cancel subscription” or “order pizza”. Alongside add a small yellow sticker that represents the actor performing the interaction.
Discussions will soon go into the direction why should user “X” perform this action? This forces people to think one layer deeper, since commands are ultimately the results of some decision.
By challenging assumptions and bringing alternative options you will make the first step in improving the overall design. That is why is important to have key stakeholders participating so that constraints can be updated or policies adjusted.
After the workshop, I usually take pictures of the entire wall and also bring the paper role in the team space so that it is always visible. When team members encounter any difficulties, they just come back to it as it represents a source of knowledge that is understood by all technical or nontechnical parties.
You can go further and build aggregates so that you can start building a domain model, but for simplicity’s sake, I will stop here and provide you bellow links towards Alberto Brandolini’s website, the inventor of this technique.
I recommend checking out his videos, presentation and grab his book where he goes in a lot more details on the thoughts behind the methods.
If you want to see the video version of this article check it out on my youtube channel.
