In 2013, Alberto Brandolini developed a workshop technique for modeling business processes called Event Storming. He aimed to create a more intuitive and collaborative approach of understanding complex systems. Let’s take a look at how Event Storming works in practice by walking through the process.
Event Storming is helpful when:
- We are creating a business model for project/service development,
- We want a picture of the complexity of the product model,
- We need to brainstorm alternative solutions,
- We are looking for bottlenecks in mature products.
Step 1: Preparation
Let’s imagine that we work for a company specializing in on-demand rides, and we want to organize a workshop focused on the development of our application. It would be beneficial for such a meeting to gather as many specialists from various departments as possible, such as programmers, IT specialists, product owners, as well as people from customer support, marketing, and designers.
We begin the workshop by introducing the purpose and principles of Event Storming. This is crucial because the session may seem quite informal, but it has its structure, and it’s the facilitator’s job to maintain that order. The topic the team will work on is also presented. Our goal may be, for example, to understand the challenges we face, find solutions to differentiate ourselves from the competition, or address common issues reported by users.
To start, each participant is given orange sticky notes and something to write with. The color of the sticky notes is significant because each phase of the workshop has its own color, and as time goes on, our board, where we stick the post-its, becomes increasingly colorful. Thanks to this, our model is naturally divided and will be easier to organize.
We will need such sticky notes for the Event Storming session.
Step 2: Let’s start with the Big Picture
We ask participants to write down important events that are happening in the system. By events we understand changes in the process. They represent moments that make a difference in the application or have business significance. Completely different events may be important for specialists from different departments and they should all appear on the board.
Importantly, we record events in the past tense. Why this way? In event storming, we present them as actual, already occurred events, not abstract concepts. This approach enhances clarity, helps avoid ambiguity, and documents the history of the system/process in action. The past tense form of an event forces participants to think in a certain way – we are not interested in the event “searching for a ride” but rather “ordering a ride” or “finding a car”.
So let’s suggest “requesting a ride” as the first and most important event. This is the basic event around which our business revolves. We can indicate events as potentially the first and potentially last in the system and continue to search for all the others happening in between.
Sample output events in the ride ordering system.
Adding events is so-called exploration. This creative session is similar to a brainstorming session and forms the basis for further work. Sometimes, during the workshop, lively discussions may arise. The clash of different perspectives is an integral part of Event Storming. The facilitator’s role is to ensure the tension is diffused and to skillfully steer the discussion to extract valuable information. It’s important to allow for free exchange of opinions while still maintaining the workshop’s structure.
One way to address contentious issues is to use hotspots, which are represented by red sticky notes. Hotspots indicate problematic issues that we want to park for later discussion. An example of a hotspot could be suggesting additional services during a ride, e.g., for the event “Selected pickup location,” we attach a sticky note with the information “If the pickup location is near a kindergarten or school, offer the passenger a child seat“.
It’s worth parking ideas so you can come back to them later.
Hotspots can also be used to identify areas that require special attention, highlight key issues that need further analysis, and mark potential threats or opportunities.
Step 3: Organizing sticky notes
First, let’s check if the events on our board are correct and not repetitive. Often, some events can be merged or combined into one much better event. Once we have order among the sticky notes, it’s time to find the right event to kickstart our path. The facilitator doesn’t necessarily need to know this in advance but must extract the relevant knowledge from the workshop participants.
Duplicates or the same events described in a different language may appear on the board.
We arrange events on a timeline axis in the order they occur sequentially. The same events may appear on the board more than once. This doesn’t indicate an error but rather shows that they can occur at different stages.
Often, after initially organizing events, the reverse narrative technique is employed. It involves going through the path backward and checking if everything has occurred to enable each event to take place. This helps uncover missing links, such as events that may have seemed too obvious and were therefore overlooked. It’s worth adding them at this point.
While organizing events, independent lines start to form, such as those directly related to the ride and the driver. Event organization is also the moment when we can discuss hotspots. This is where we address and resolve hotspot issues.
This is what organized events look like on the board, branching off into independent paths.
Step 4: Time for actors and systems
After organizing the events, we start adding small yellow sticky noteson the board to symbolize the actors. These help define the people who trigger each event: customer, driver, admin, etc. Thus, an actor stands for a role in our system. Next, we add pink cards that indicate the services and systems used in the application, such as the booking path or the notification system. These can be either internal or external.
Initial customer path with labeled actors and systems.
Step 5: It’s time to look for problems or… opportunities
Once we know everything about our service, it’s time to go back to the very beginning of the meeting and recall its purpose. If you find that you’ve found more than one problem or opportunity, it is worth choosing one key issue. To do this, approach the selection of next steps constructively. We can involve all participants and conduct voting. Before this happens, it is worth using the knowledge of people from customer service departments. They are the ones who stand on the front line and receive requests directly from users – it’s good to listen to what they have to say. We can also ask the Product Owner how he sees the next steps, as he is the one who will be in charge of developing/improving the service.
This concludes the Big Picture session. Let’s move on to a deeper analysis.
Krok 6: Event Storming at the process level
This stage is supposed to bring us closer to solving the issue we have chosen. We start the process level session by choosing a specific place in our system and defining commands. Blue cards marking commands, i.e. intentions behind a given event in the path, will help us with this. Commands are issued in command mode by actors.
In order for commands to be handled positively, it is necessary to enter business rules (purple cards) into the system. A rule can be about the history of rides, ratings received from drivers or cancellation conditions. In our case, it is a rule that generates an offer after ordering a ride. Positive verification allows the command to work.
Initial customer path with labeled actors and systems.
After this stage, all we need to do is Design Level Event Storming, i.e. create a target model that we will transfer 1:1 to our system or application. This part already involves mainly technical people who implement the solution into the code.
At the beginning of the article, we presented all the cards that are used during Event Storming sessions. Some of them – white ones for definitions and yellow ones for comments – we did not include in our examples, but that does not mean that they are less important. On the contrary, every now, and then it’s useful to think about what we mean by a word or phrase, write it down and put it on the board so that all workshop participants understand the item in the same way. The same is true of comments – you can add them when you have an important remark or thought about an event or place in the process.
Summary
When developing a product, it is important that the development team is well-versed in the domain in which the product operates. Workshops like event storming can improve overall collaboration between business and product teams.
Key advantages of Event Stroming sessions include:
- Speed: Most business process modeling techniques require some digging in business operations. They therefore involve the use of complex data models and can take weeks to complete. Event Storming is typically a one-day event during which a complete business process can be mapped within a few hours.
- Common understanding: Event Storming demonstrates a business process that can be easily understood without prior technical knowledge. It is a bridge between technical and non-technical stakeholders.
- Collaboration: The basic concept of Event Storming is to encourage participation
- and interaction between experts from different fields. This creates a natural environment for creating business models and leads to the discovery of valuable insights.
- Effectiveness: Teams can apply the knowledge gained from the workshop to future modeling and product development processes, or simply to better understand business processes and make better decisions in the future.
