Event Storming is an engaging technique for rapidly modelling a process as events along a timeline by business and technical people together during the Event Storming workshop. This storming method is very useful for creating a business model for development projects and obtaining a shared understanding of important business problems.
If you have been researching Event Storming you probably started to wonder how to run the first successful session. If that is the case, this article is for you. It will take you through the setup process and the event structure and provide you with useful information on how to organise it properly.
What is Event Storming?
Just a quick reminder, Event Storming is a workshop-based method used to find out what is going on in the domain of software programs. It has its roots in domain-driven design approach (DDD) and is used to create a business model. As a result of the Big Picture workshop, you can visualize the model of the product with its complexity, highlighting its goals, opportunities and uncovered issues. The results of an Event Storming session are presented on a wide wall using the sticky notes, where each event is represented by a separate sticky note.
The power of this session is impressive as during the couple hours you can really identify gaps, bottlenecks and areas of conflict as well as discuss solutions. You can find more about the benefits of Event Storming in my latest article Event Storming: How It Will Improve Your Business Processes?
Define your needs: Collaborative Discovery
An Event Storming session usually starts with a topic the group wants to work on during the session. The first step is to define your needs.
Examples of these topics may include:
getting everyone on the same page with the problem definition,
exploring a particular area of business;
looking for ways to improve an existing business capability;
discovering and designing work for a new business capability;
challenging a proposed software solution by modelling the domain in several different ways.
As with any other workshop session, a big part of a facilitator’s job is to help the participants align quickly around the goals, approach and timebox for the session.
It’s important to invite the right people to the workshop, striving for a diverse mixture of people with relevant business and technical experience. Involve the appropriate subject matter experts (e.g. users, product owners, business analysts, representatives from other teams, etc.) to participate and share their insights on the business.
Event Storming is a facilitated workshop and it is important to follow some steps which help to run a session effectively.
In the next sections, I will highlight the key steps necessary to set up an effective Event Storming session and describe briefly what the typical Event Storming workshop looks like.
How to set up the workshop: basic steps to follow
It is important for an effective Event Storming session to follow the basic steps. Below you can find the key requirements and elements you should arrange to facilitate the Event Storming workshop successfully.
Click here and watch the video about the Event Storming session
Organize The Right People
The key element of a successful Event Storming session is to invite and gather a group of people who know their stuff, i.e. software developers who can ask questions about what should happen and how the system should behave together with business representatives who know the answers to those questions. Ideally, you should have 6-8 people with the right mixture of the ones who know the questions to ask and who are curious to listen to the answers and the ones who actually know the answers. You also need a facilitator to guide them through the process of exploring events, commands and grouping them into aggregates if you don’t want or can’t be such a person or just feel more comfortable if you have assistance in that manner.
Organize The Right Space
It is extremely important to provide unlimited modelling space - it can be either a wide wall for sticky notes or a very long piece of paper and a relaxed atmosphere.
Too often complex problems are not properly analyzed because there is not enough space available to dig into the problem. The facilitator of the session has to remain focused on the available area during the session in order to create more modelling space before the participants notice that there is no more room to add a sticky note. It is to not break the flow which participants are in and lose the momentum or a great idea. When they stop it will be difficult for them to get back on track.
Brandolini advises that all tables and chairs should be removed for the session time and the participants should stand in front of the wide wall.
Have Workshop Facilitator
Having all the relevant people in the same room, without a plan on how to manage the interaction between them could be a recipe for a disaster. A facilitator knows what to do to keep the workshop running smoothly and keep the participants engaged and focused. He/she can offer the instructions on the Event Storming session and make corrections without disrupting the momentum of the storming out.
During the session, the facilitator asks open questions and leaves participants in silence to encourage their participation. It is good to make extra effort to engage all the attendees. The facilitator needs to put special attention to that since it is easy for participants to distract and disengage during the long workshop.
Prepare Materials Needed
Next to organizing the right space, you need a bunch of materials necessary to run an effective Event Storming session. Please avoid the situation where you are out of sticky notes or out of modelling surface, cause it has a really big impact on the results of the session.
The materials needed are as follows:
A lot of sticky notes in various colours, ie: orange, blue, purple, green, pink, yellow;
Large modelling surface ("butcher’s" paper or a paper roll, e.g. from IKEA), in some cases you can also use a wide wall or wide whiteboard,
Sharpies or markers (for writing on the sticky notes),
Painters or artists tape (to attach the paper to the wall) - it is safer for a wall or a masking tape.
Scissors (for cutting the tape to length).
What does Event Storming Workshop structure look like?
An Event Storming session starts with a big piece of white paper tacked up on the wall as a modelling surface, a bunch of markers (one for each participant) and a lot of sticky notes in various colours (each color has a traditional use). The white paper should be vertically oriented, with an arrow drawn across the top from left to right that represents the time arrow. Sticky notes are placed chronologically from left (earlier in the past events) to right (later in the past events). The modelling surface should be as big as possible. There may be a lot of events to map.
When the modelling surface is ready and everyone has a marker, it’s time to start the Event Storming session.
Phase 1: The Orange Sticky Notes
The first phase is all about ‘storming out’ the business process as a series of _Domain Events -which are indicated by orange sticky notes (according to the convention).
A Domain Event is something meaningful that happened in the domain. It can be easily translated into software, but the real value here is that it could be quickly grasped by non-technical people. Events are written in the past tense as if everyone is looking back on the completed process narrative. For example, write ‘order submitted’ rather than ‘submit an order’, or write ‘account was created’ rather than ‘create an account’.
The group of invited people performs an initial brainstorming session where everyone writes on sticky notes as many events as possible at the same time. Next, participants start placing sticky notes with the events on the modelling surface in a timeline sequence starting with the earliest events on the left. Putting the sticky notes in a timeline sequence doesn’t have to be precise at the very beginning, since it is easy to sequence them later. So be more focused on the events themselves than their timing.
Phase 2: The Blue Sticky Notes
Once as many orange event sticky notes as possible are in place, it is time to pull out the blue sticky notes. They represent Commands or inputs that result in the event. As such, they are placed immediately before the corresponding orange sticky note and written in the present tense, e.g. ‘create a user account’, ‘remove the payment method’, ‘sell a ticket’ etc. At this step, we should also add an actor sticky notes that execute the command since each command needs ‘a commander’. If the actor is a person who performs the action, e.g. the end-user, or administrator - this is usually represented by a small yellow sticky note with a small figure on it. The actor could also be a program, like a Cron or Continuous Integration (CI).
Phase 3: The Yellow Sticky Notes
In this phase, we are looking for Aggregates as a little self-contained cluster (event with its corresponding command and the responsible actor). Instead of defining aggregates starting from the code, we’re taking an outside-in approach: the Aggregate is the portion of the system that receives commands and decides whether to execute them or not, thus producing a Domain Event. Aggregates logically group various commands and events, together. The aggregates are written on slightly bigger yellow sticky notes.
In conclusion, the first step is to find the Domain Events and write them on orange sticky notes. When all domain events are found the second step is to find the Command that caused each of the Domain Events. Commands are written on blue sticky notes and placed directly before the corresponding Domain Event.
In the third step, the Aggregates within which commands are executed and where events happen are identified. The Aggregates are written on yellow sticky notes.
Other Sticky Notes
Outside of the basic creation of domain events, commands and aggregates, the following other sticky notes can be used to add context to the model:
Purple sticky notes represent a business process or business logic that creates one or more domain events, e.g. billing policy.
Pink sticky notes represent external systems which might create a command instead of an actor within the domain. It is a third-party service provider such as a payment gateway or shipping company, e.g. external payment system like PayPal.
Green sticky notes represent a view that users interact with to carry out a task in the system, e.g. order list or order summary.
Red sticky notes or any other colour you have leftover may be used for questions, concerns or issues around an event or an aggregate that will need to be discussed and addressed later.
Summing up, as a result, the business process can be seen as a whole onto the modelling space. But more important is the knowledge that was built in the minds of the participants.
The concepts gathered during an event storming session fall into several categories, each with its own colour of sticky note:
Although the many colours of sticky notes may look a bit chaotic at first sight, Event Storming modelling spaces are actually a picture of a business model getting done. The domain knowledge the Event Storming session extracts and the time taken to accomplish is powerful.
Summary
With the right people invited and a bunch of sticky notes, the different parts of a complex domain come into focus and the whole business process is visualized. It is also a great chance to learn about dependencies in the entire domain that might be less visible on a daily basis, but can significantly affect decisions made about the product, both on the technical and business ends.
If you are looking for an experienced Event Storming facilitator, we can provide you with a Process Facilitator/Scrum Master that will help you implement Agile practices into your projects and facilitate Event Storming sessions from the very beginning of your project and/or on mature software. Feel free to fill out the contact form to get a quote.
Selleo can also help you with the development process. Our Agile, fully-fledged teams are ready to build you an extraordinary product.
The key difference between Event Storming and Event Modeling lies in their scope and approach.
Event Storming focuses on exploration and discovery, using a collaborative, unstructured workshop to uncover domain events and gain a shared understanding of the system’s behavior. It emphasizes brainstorming and is often used in early stages of a project for domain exploration or problem identification.
Event Modeling, on the other hand, is more structured and aims at creating a detailed blueprint of a system’s design. It combines domain events with user interactions, system views, and workflows, visually mapping out the system from end-to-end. While Event Storming is ideal for discovering what needs to be done, Event Modeling is used for planning how to implement it in a precise, actionable way.
