Process level event storming: What it is and how to start the workshop
Have you ever faced difficulties during sprint refinement, trying to get on the same page with your team? Perhaps, after implementing a solution, it turned out that it should look a bit different?
If any of these situations have occurred, or if you're wondering how to define the scope of work without getting too technical, Event Storming might be a great fit for you. Whether you're new to the domain or just need some alignment, the "Big Picture" type of workshop is a valuable tool I've used on several occasions, making my job a lot easier. However, while the high-level overview provides clarity, it lacks the necessary details for implementation. In this blog post series, I'll guide you through conducting such a session, enabling you to translate Event Storming output into your codebase.
The topic is vast, with plenty of materials available to help you tailor the session to your specific needs. Yet, when I first attempted to conduct such a session a few years ago, it proved more challenging than some sources suggested. After conducting multiple sessions and participating in various training workshops, I've developed my own style. This approach has been used successfully in both corporate and startup settings, making Process-Level Event Storming a key component of my discovery workshops, aiding in the design of accurate backlogs and contributing to the successful delivery of software projects.
If it’s the first time you hear about the technique, it could be better if you started from more general materials available here. You can also find more sources in the last section. But if you already heard something about it and you would like to deepen your knowledge, I hope you can find valuable information below.
So let me introduce you to my flavor of the method, hoping it will help you adapt it to your needs and elevate your software design game.
Before delving deep into theory, let's embark on the journey of a workshop. In this blog post, we'll initiate the workshop kickoff, with subsequent articles exploring domain exploration and software design based on the Event Storming board.
First of all, who do you invite to such a session?
That depends but this time we’ll have to go deep into details, so it’s better to focus on a specific domain. Ideally you already have an outcome of big picture event storming so you can invite people interested in specific domains as a wider audience may quickly get bored with topics which do not adhere to them but it is possible to skip this step if you re familiar with the domain enough so you can clearly define what you will be talking about e.g. you just want to add new feature to your software so maybe your scrum team and som one or two additional stakeholders like architect and other technical manager will be enough.
For a commercial workshop I usually asked for key stakeholders such as Enterprise/Software Architect and some representatives of teams/domain experts with which we know this domain may need to integrate. Which may be managers or experienced employees, it depends.
For me, event storming is all about telling the stories from different points of views so let’s start with a story for an introduction. A role play, to be precise.
Imagine that you are the owner of the gas station and you would like to improve the customer experience possibly by introducing some software, but you are not sure yet. And this is the goal of the training which we use to cut short the possibilities.
It needs to be a simple topic which everybody knows so they can familiarize themselves with building blocks without thinking too much on the proper solution. Also this part should not take longer than 5 minutes as we have the whole workshop to conduct. I know this is a bit fuzzy but I need you to trust me for a bit. It will become a lot clearer in a few minutes.
So first things first. What are the factors that let you decide that you even need to refuel?
Some of them may be:
We notice the we are running low of fuel
Maybe we have a planned trip and want to start with a full tank
We would also take into the account which gas stations are near or along the way
Also gas stations often offer discounts for returning customers so it would be perfect to pick one which will be the cheapest
Maybe we work for organisation which can only refuel at certain stations
Ok this time we don’t need to get them all so this is enough so what we would do with this information?
Let me introduce you to the first building block, the Read model.
It is a green post-it which represents the information needed to make a decision.
Colors for each building block are up to you but it’s mandatory to stick to the only you choose as it would improve readability.
Ok we know what intel is needed but who does make the decision?
In this case the driver
Great, let's model that!
This is the second building block, the Actor. This may be a specific person or the role which acts upon the read model. And we model it with yellow post-it.
So what does this actor do when they decide that it is the time to refuel?
They pull off into the station
OK
This is yet another building block, the Command. Represented by blue sticky, which models exactly what the name suggests
Great so what happens next?
Oh, the driver pulls off and starts refuelling.
Wait a second, there isn’t anything in between? How do they get in, maybe there is something which would block them from doing so?
Well they drive through the driveway and then they decide which distributor to pick. Ok so here comes the next building block, the External System
The External System has a really imprecise definition but long story short this is something we can put a blame on. So it can be piece of software, a department or like in this case physical object
Ok, so the driver pulls off, goes through the driver and once they are in, they pick the distributor.
This is pivotal point in this process since we finally can act upon it so let’s model it with next building block
The Event, a verb in the past tense which models an event at a given time which is important to the process. E.g. If it triggers some process changes or interactions it would be wise to model it but if we go too deep we may end up with a lot of noise so we need to focus on events which relate to our goal. But let’s not worry too much about that at this time we will validate and improve the process so we can work both with too little and too much of the events, but we don’t want to discourage participants from speaking their mind.
So what happens once the driver arrives at the station? Is there anything which always happens when they arrive?
They need to pick up the position as they may be the line to some distributors.
Here goes the next building block, the Policy
Policies are rules, and habits which happen in the process. They happen after the event and they can follow the template “whenever X then Y” or “Immediately after X happens Y” Policies may be fully automated or driven by actors.
In this case the driver makes the decision so how do they do so?
Well, depending on the line length and the fuel type available at the distributor.
Let’s model that
What happens next?
After the driver picks the distributor they drive to the position.
Ok, this could look like this
Once they are in, if there is some employee at the distributor they can refuel the tank but if noone is around, the driver can do that themselves.
Since this is just an example, let's focus only on the bottom one.
Ok, so the employee refuses the tank
Here we’ve added the black post-it as the Hotspot, this could be the information which we want to talk later on during the session or event could be a start for some other discussion
What’s next?
When the employee finishes the tank is set to the requested level
Cool, we can stop this process for now. Let me show you what happens next.
Now we need to validate it. There are several ways to do it but now we can do my favorite one, speaking the story out loud, and it needs to be out loud.
This is just how our brain works once we speak out loud it a lot easier to track inconsistencies.
Ok so I can try.
Driver, drives the car and notices that they are running low on fuel. There is a convenient gas station nearby so they pull off through the driveway and once they arrive they pick the distributor where the employee refuels the car.
Hm, but what if more people were there?
They may decide to leave for another station. Maybe while they wait in the line we can offer them hot beverages or show them our promotions.
Then it looks like there is something in between.
The last building block is the Aggregate.
You can think of it as a state machine/component which is under our control
So the process which we talk about could look like this
There are a lot of things which we could improve but this is good enough. Before we go with the workshop to the real domain, let's write down how we're gonna work.
The grammar must be respected. That means that we will use the building blocks and orders of post-it must be as described e.g Command cannot be placed directly after the event
Every path must be completed and in the stable state, so ends with either read model or event
Every hot spot needs to be addressed, We need either to resolve it or mark it for the follow up session(doesn’t have to be event storming)
Every stakeholder needs to be reasonably happy. In these sessions we wan’t to align so every possibility should be discussed even if only to be discarded.
Don’t worry if not every participant catch it fully, that why there is facilitator on the session so when we go for the real domain there is still room for technical questions
Depending on the group I often start from the rules and then go for the example but it depends whether the group has any analytical/technical background so they won’t be overwhelmed with too many definitions from the start.
That would be it.
In the next article we’ll explore the real domain and after that I’ll show you how to make software out of it.
Below you can find my sources and list of places which I recommend if you are interested in the Event storming
