EventStorming - Collaborative Learning for Complex Domains • Paul Rayner • YOW! 2016

Event storming bridges the gap between business and tech, transforming complex conversations into collaborative understanding.

Good day, Melbourne! I came a long way to do this, and I'm excited to be here. Today, I will be talking about event storming, a relatively recent technique that has emerged in the last two or three years. This method is particularly useful for teams working in complex domains. If you are involved in a business that has a lot of complexity in its operations or if you are dealing with legacy systems—code that has been around for a while that you are trying to integrate or innovate upon—then event storming can be incredibly beneficial.

Over the past couple of years, I have been experimenting with event storming and applying this technique with various teams. I have observed that it helps bridge the gap between the business and technical teams in ways that I hadn't seen before. This process fosters a new level of collaborative learning between these groups. My goal at the end of this talk is to help you understand what event storming is, how it might assist your team, and provide you with some tips for facilitating an event storming session. I hope some of you will try it out with your teams, and I will also share some resources for that.

To give you a bit of background, the book "Introducing Event Storming" is available on LeanPub, published by Alberto Brandolini. Like all things on LeanPub, it is mostly done but still contains a wealth of information. My background is in domain-driven design, which has been my main area of focus for almost ten years. In the Domain-Driven Design book, Eric Evans states that the critical complexity of most software development lies not in the technology but in understanding the domain itself. This understanding is often the most challenging aspect, and as technical people, we are not provided with many tools to achieve this.

To illustrate this point, I want to reference the Rosetta Stone, which is housed in the British Museum. I saw it again in June, and it is famous for having three languages inscribed on it. It was the first archaeological artifact that allowed scholars to decipher Egyptian hieroglyphics. Before its discovery, no one understood what was written inside the pyramids or other locations where hieroglyphics were found. The Rosetta Stone provided a translation of the same text in hieroglyphics, demotic script, and Greek, enabling scholars to use what they knew to understand the other languages.

I often see teams in a similar predicament. They speak in technical languages—like Angular, REST, and other jargon—while the business side communicates in terms that seem like hieroglyphics, discussing invoices, purchase orders, or whatever your specific business domain entails. Bridging this gap is a core concern within domain-driven design, and it is where event storming can be particularly effective.

So, what exactly is event storming? The idea is to place events on a timeline. In domain-driven design terms, we refer to these as domain events. During an event storming session, we represent these events on orange sticky notes. Participants are given Sharpies to write these events in the past tense on the stickies. You might wonder why we use the past tense; it is because an event is a fact—it is something that has already happened. We do not change it because it is already in the past, unless, of course, you have a TARDIS, a flux capacitor, or a DeLorean, but we won't go there!

These domain events are not necessarily things you would find in a log file; rather, they are significant occurrences that the business experts, or domain experts, care about.

=> 00:04:50

Domain events capture the moments that matter in business, written in the past tense because they are facts that can't be changed.

In domain-driven design, we focus on the concept of a domain event. We represent this in event storming using an orange sticky note. Participants are given Sharpies to write these events in the past tense on the stickies. You might wonder, why do we write it in the past tense? The answer is simple: it's an event, a fact, something that has already happened. You don't change it because it has already occurred—unless you have a TARDIS or a flux capacitor in a DeLorean, but that's a different discussion.

The key point is that these domain events are not merely entries you would find in a log file; they are significant occurrences that business experts, or domain experts, care about. We need to consider what kinds of events these experts might find important. To illustrate this, let’s look at some examples of what we mean by a domain event.

A domain event represents something that has happened in the business that the domain experts care about. For instance, we might have a sticky note representing a time-based event, such as the end of month. Following this, we could have an event where the billable amount is calculated at the end of the month. After that, we would want to verify this amount, leading to the event of the billable amount being verified. Finally, assuming everything goes well, we would have the event of an invoice being prepared.

The idea is to place these events chronologically, from the earliest to the latest, on a modeling surface. In terms of the types of events, we can categorize them into different species of domain events. The most common type is a step in a business process. Examples of this might include customer order submitted, customer paid a certain amount (which could be relevant in an e-commerce context), or item shipped. These are all steps in a business process, which may also include approval steps for published items.

Another category includes events that occur on a scheduled basis. For example, we might refer to the end of month or nightly account reconciliation in a transactional industry. Additionally, an interesting aspect of events is that they can trigger other events. For instance, in baseball, after strike one, if the batter swings and misses, it becomes strike two, then strike three. After the third strike, a different event is triggered: you're out. Similarly, three outs can trigger the end of an inning.

In a technical domain, consider an example where a customer tries to log in three times in succession and fails each time. The next event that would occur is account locked. This pattern is quite common in our systems, although we may not typically think about them in terms of events. Our industry has traditionally emphasized modeling in terms of structure, focusing on objects, nouns, and verbs, as well as database structure. While these elements are important, event storming shifts our focus to changes in state over time.

When we conduct event storming, we provide unlimited modeling space. What does this mean? I typically use an Ikea roll of butcher paper that I put up on the wall. I want to create a space that can accommodate the size of the modeling, which I cannot predict in advance. This allows participants to feel free to spread out and place their stickies wherever they need to. When they enter the room for an event storming session, they will see the butcher paper on the wall, a large visible legend explaining the different color codes for the stickies, and a pile of supplies available for their use.

The process begins with a single event, and from there, we start to branch out, exploring what happened next.

=> 00:08:50

Creating a collaborative space for event storming transforms chaos into clarity, allowing teams to visualize their journey from problem to solution together.

I mean by that, I have an Ikea roll of butcher paper that I'll typically put up on the wall. I want to provide it to be flexible because I don't know how big this modeling is going to get ahead of time. I want people to feel like they can spread out and put these stickies anywhere they need to when they come into the room for an event storming session. They'll see the butcher paper on the wall, a big visible legend that explains the different color codes for the different stickies, and examples of those. There will also be a whole pile of supplies there for them to use.

The idea is that we have our modeling space and start with a single event. From there, we begin to branch out. We ask questions such as: What happened that triggered this event? What caused this event? What happens after this event? What are the results from that? You think about it in terms of putting the first event up, which may be the last one. For example, consider the story of Cinderella: they lived happily ever after. But what does it start with? It's a fairy tale, so this is not usually how software development goes. Typically, something bad happens at the end, but hopefully, there’s something good that happens.

In this context, we have domain events; they lived happily ever after, and it's in the past tense—something that has happened. If you think about the story of Cinderella, there’s a whole bunch of stuff that happens between those two points. However, who knows ahead of time how much detail we need to go down to or what we need to focus on? Therefore, I like to have a big space available because I don't know how much space we're going to use up.

In terms of an event storming session, we want to invite the right people. So, who do we invite? If we know what kind of problem we're trying to solve or what kind of thing we're digging into, we want to ensure that we have people from the business side who understand that part of the business and what they're trying to achieve. They need to understand the business process. I rarely find someone who knows the whole thing end to end; it’s usually several people with different areas of expertise that somewhat overlap. I want to make sure that I have a few people in the room.

You can see this is a team that’s just getting started with an event storming session. This is actually a mixture of developers, an architect, and several people who are experts in this particular business domain. They’re having conversations around the orange stickies representing events, and they’re building up a visual map of this timeline as an artifact that they can discuss as they go along.

It's really hard to capture the energy of an event storming session. I've tried videoing these sessions, but you really just see people writing on stickies and sticking them on the wall while talking to each other. It doesn’t truly capture the energy that I feel in the room when I’m part of one of these sessions. A couple of months ago, I did something a little different; I actually time-lapsed an event storming session.

In this session, you can see we have all the supplies. We’ve also got output from a previous event storm session at the bottom because this team wants to develop some new features. They had mapped out a previous process that’s somewhat similar to the one they’re going to be working on, but a little different. They wanted to have it as a reference, so we put that underneath the blank section they’re going to be working on.

As the facilitator, I seated the wall with a single event. At the start, I’d say, “What’s something that a domain expert cares about?” Then I’d write it down and stick it up on the wall. I might seed that with another event and then say, “Okay, now that I’ve explained how this works, go.” This is what it kind of feels like when you do event storming.

In this particular session, there are about 10 or 15 people all collaborating together. You can see that they’re building up this map very quickly on the wall, and in terms of the events, they’ve also got...

=> 00:12:35

Collaboration thrives when everyone speaks the same language, turning complex processes into clear, actionable insights.

In the event storming session, we begin by placing a blank section on the wall where participants will be working. As the facilitator, I start by seeding the wall with a single event. I ask the group, "What's something that a domain expert cares about?" and then write it down and stick it up on the wall. Following that, I might prompt for another event, and then I explain how the process works, saying, "Okay, now that I've explained how this works, go."

The atmosphere during event storming involves about 10 to 15 people collaborating together. They quickly build up a map on the wall, writing down events and sticking them up as they go. Participants use pink stickies, which we will discuss later, and as they write down events, they engage in discussions about any questions or uncertainties. The goal is to build up a timeline first, reviewing each other's contributions and moving around the wall to grasp the overall process. At various points, they pause to identify which parts are most relevant to the new features, discussing what is in scope and what is out of scope. These conversations happen in real time, fostering an interactive environment.

As a facilitator, I maintain a balance in the room. I know the process but do not possess in-depth knowledge of the business domain. My role is to create an environment conducive to the right conversations, ensuring that no single person dominates the discussion and that we take necessary breaks. This contrasts sharply with my experiences in traditional meetings, where developers might approach a whiteboard to sketch detailed UML diagrams or database structures. In those scenarios, I often notice the business people's eyes starting to glaze over as we drift into technical territory that doesn't resonate with them.

In contrast, during event storming, it is the business experts who lead the conversations. They connect events, pointing out relationships and loops in the process. I introduce orange stickies for domain events and pink stickies for uncertainties right from the beginning. In the first round, I instruct the team that these are the only two colors they need to focus on. The orange stickies capture the timeline and sequence of behavior, while the pink stickies are used to note questions or assumptions.

As we build the map, potential problems, risks, and concerns begin to emerge. This visual representation helps identify hotspots in the process. Sometimes, the best solution is not to develop software for a particular area but to reassess the process itself and recognize that it may no longer make sense. For instance, in the session I observed, the team identified a section of the process related to their Legacy system that was out of scope for them. Despite this, they noted that many aspects downstream from that section were still relevant and needed attention.

=> 00:16:31

Sometimes the best solution isn't new software, but rethinking and improving the existing process.

In the process of mapping out potential problems, potential risks, and potential concerns that people have, it becomes evident where the hotspots lie. Sometimes, the right solution is not to write any software for that part of the process at all, but rather to examine the process itself and determine that it needs improvement because it no longer makes sense.

For instance, with a particular team I was observing in a time-lapse, there was a whole section of the process they identified as a Legacy system that they weren't even really touching. They acknowledged that this part was out of scope for them, yet many aspects downstream from their work would be impacted. This realization emerged during our discussions, highlighted by the pink stickies that represented various issues. Another common challenge that surfaced was confusion around terminology. For example, questions arose about whether one domain event that discusses a claim relates to another domain event that also talks about a claim, and if they are indeed the same thing.

I provided an example of event storming to illustrate how new functionality could be integrated and what that looks like for a team. I found event storming particularly beneficial when working with applications that have been around for a long time, especially large applications. You might be in a situation where you're dealing with code that is 5 to 10 years old, developed by many people over a long period, and it may not cohesively fit together as it should. Often, these applications are large, distributed, and integrate with third-party systems, which complicates matters further.

One specific case I will share involved working with an architect on a large-scale Internet of Things application that had been developed over about nine years and is still in active production today. This application managed various types of devices, requiring the ability to add video cameras, webcams, thermostats, and other devices. The process for adding devices and having the system recognize them varied significantly by device category, making it challenging to grasp the overall picture. Each category had its own separate modules and sections of code, developed by different groups of people.

To address this, the architect and I spent a couple of hours mapping everything out to gain a clearer understanding of the big picture patterns. The resulting map illustrated different categories of devices across the top row and further sections on the left and right. We identified some common patterns in the flow, but also noted drastic differences in the implementation of each category. Our goal was to explore opportunities to consolidate some of the code or at least standardize the handling of the process.

The event storming session felt quite different from the previous one I had shown, as it involved a smaller group and focused on an established system from a technical perspective. Dan, the architect I collaborated with, was the domain expert in this case, possessing a deep understanding of how to integrate all these different devices together.

In the mapping process, we also incorporated various colors beyond just orange and pink, which allowed us to model different kinds of interactions using event storming. This approach provided a comprehensive view of the system and highlighted areas for potential improvement and consolidation.

=> 00:20:34

Collaboration thrives when everyone understands their role—use personas, commands, and data to clarify the path forward.

Here's a structured overview of the event storming session led by Dan, the architect I worked with. He was walking the rest of the team through what we had come out with. This event storming felt very different from the one I showed you before because it wasn't 10 or 15 people in a room with business experts. Instead, it involved walking through an established system, very much from a technical perspective and within a very technical business domain. In this case, Dan is actually the domain expert because he understands the intricacies of how to integrate all these different devices together.

During the session, we utilized various colors of stickies to represent different types of interactions. For instance, one very common interaction involves a persona or some kind of user performing actions and interacting with the software. We used yellow stickies to represent these personas or users. When that person performs an action, such as "submit invoice," we used blue stickies to represent that decision or command happening within the system. If you're working on a system that employs the command pattern, this will look very familiar, as the blue stickies represent an imperative to tell the system to do something, like "submit invoice" or "publish workflow item."

Interestingly, commands often lead to one or more events. For example, there is often a parallel between an action like "submit invoice" and an event that states "invoice submitted," especially if you're using an event-based architecture. Therefore, we have blue for commands and yellow for users. I particularly enjoy working with teams that have well-established personas in terms of user experience design because it makes this type of workshop run much more smoothly. The team members really understand what the personas mean and what kind of archetype of user they represent, which enhances the flow and understanding of the session.

Moreover, while users or personas need to make decisions, they also require information and data. To represent this need, we used green stickies to denote what we would call a read model or some kind of data that the user would be interested in. This data is something that gets displayed on the screen, and the idea is to present information that will assist the user in making decisions. In systems that are fundamentally event-based or when using a functional language, this green sticky often takes the form of some kind of projection of the state of the data. For instance, if you're representing an invoice as a series of events in your system, you would need to create a projection to determine the current state of that object and present it as a green read model.

As we progressed through the workshop, you could see people actively using the different colored stickies. They were putting up pink stickies to indicate things they didn't understand. They had a list of personas at the top that they were referring to, and even if someone didn't know anything about this particular domain, it was evident that certain areas were more problematic than others in terms of the team's understanding. For example, there were more pink stickies towards the beginning and the end of the session, indicating potential gaps in knowledge.

If I see a lot of pink stickies, it may suggest several things. It could indicate that the person who knows the answers to those questions wasn't in the room, prompting the need to schedule a follow-up workshop or some action item to chase up that person. Alternatively, it could simply mean that the team doesn't know the answers at all. Sometimes, I conduct event storming sessions to address these very issues.

=> 00:24:22

Identifying gaps in understanding during a workshop is a win; it means you're on the right path to clarity, not rushing into coding blind.

In the context of event storming workshops, certain areas can be identified as more problematic than others regarding the team's level of understanding. For instance, somewhere towards the beginning of the workshop and over here towards the end, there are more pink stickies. This is an indication that several factors could be at play. If I see a lot of pink stickies, it suggests that perhaps the person who knows the answers to those questions just wasn't in the room. This raises the question: do we need to schedule a follow-up workshop or some kind of action item to chase up that person to find out? Alternatively, it could simply mean that the team doesn't know the answers at all.

Sometimes, during event storming workshops, we end up with more pink stickies than orange stickies. In such cases, the next action is probably not to go to your IDE and start coding. Instead, it indicates that the team's level of ignorance is significantly higher than their knowledge level regarding the problem they are trying to solve. This outcome is actually beneficial for an event storming workshop because if we conclude an hour with a sea of pink stickies, we recognize that there is much more work to be done to clarify what we are trying to build. Discovering this early is preferable to finding it out later.

The advantage of having the relevant people from the business and the team in the room is that it facilitates a consensus on the fact that we are not ready to move forward yet; we still have more work to do. This work might involve prototyping, further discussions with the business, or a more careful consideration of the problem we are trying to solve. It may also require identifying who else needed to be in the room for the session.

There are common patterns regarding where domain events originate. The first pattern is that it may stem from some kind of action that is started by a user. This is represented by a yellow sticky, indicating the user or persona involved. The command associated with this action is a very common source for events. As a team engages in event storming, if I see an event just dangling out there, I will inquire, "What caused that? Did somebody do something that actually led to that event happening?" It is quite rare for events to simply emerge out of thin air.

Another prevalent source of events is external systems. We represent these events with a lilac or purple color. These events could come from various external systems, such as a payment gateway sending back a response or a system that, while still within the company, is external to the specific application being worked on. This approach allows us to delve into not just the user-facing behavior but also the underlying processes occurring behind the scenes. We can identify the actual events coming from other systems that trigger actions in our application or require our application to respond.

Additionally, I mentioned that events can occur simply due to time passing. For example, I recently worked with a team that had a rule: if no action was taken on a certain item within 90 days, something needed to happen. This pattern is quite common in many domains, where a specific period of time elapses without action, or a certain type of action occurs, prompting another event to be triggered. Thus, we can model these interactions effectively.

=> 00:28:29

Modeling the flow of events in your system reveals the real story behind your software, where the magic and the bugs truly lie.

To effectively define the boundary of our system, it is essential to model that boundary by utilizing a flow of events. This approach allows us to keep our systems loosely coupled and maintain a good interface between our system and any other system it interacts with.

One common scenario I encountered recently involved a team that needed to take action on a specific item within 90 days. If no action was taken during that period, something had to happen. This type of pattern is prevalent in many domains; it often involves a certain period of time passing without action, which then triggers another event. For instance, you can model this by creating a domain event that states, "90 days past" or "one week elapsed." From there, you can determine what happens once that event is triggered and model the subsequent actions accordingly.

This technique is powerful because many teams do not typically think about their domain in this way. What we are discussing here is modeling chronology; we are actually modeling time. Traditionally, I was taught to focus on structure—what the form of things is and how to persist them. However, the most interesting aspects of our software, and where most bugs occur, arise when changes happen. How many bugs occur in your system when data is not doing anything? Very few. It is during changes that issues tend to arise. Therefore, through event storming and an event-based approach, we aim to capture those meaningful changes and model them effectively.

Additionally, it is important to recognize that sometimes one event triggers another, or a sequence of events leads to another event. These are four common patterns I look for during an event storming session with a team. For each event present, I ask, "How did it get there?" This inquiry allows us to visualize business rules. For instance, if someone states, "Whenever this happens, we need to do this," it indicates a policy. We can represent this policy with a specific color, such as a light color. For example, if someone mentions, "Whenever the price exceeds a certain amount, we need to perform some other kind of action," we identify that as a policy leading to a command, which then triggers a sequence of events. This method allows us to model business rules, process management, or long-running processes effectively.

As a facilitator during an event storming session, my role involves asking a lot of questions. If I notice an event that seems isolated, I might ask, "What circumstances caused this event to happen?" or "What was the path that led us to where we are right now?" Each event assumes a context that may not yet be visible, so I often prompt participants to "Tell me the story of how we got to where we are right now." Furthermore, I might inquire, "Are there other ways to get to where we are in terms of this event?" This exploration helps us understand the timeline and delve deeper into the context.

Another effective question I use is, "Can you give me a good example of something?" This question is particularly powerful for technical individuals, as we often focus heavily on technical aspects and may struggle to engage with business concepts. By asking for a concrete example, such as "What does a limit of liability mean?", we can better understand these domain concepts and the business terms that everyone assumes they comprehend until they are required to explain them. This realization often leads to deeper insights and understanding within the team.

=> 00:32:46

In meetings, focus on exploration and learning, not just decision-making.

Understanding what that timeline looks like and starting to dig into that is crucial. One powerful approach is to ask, "Can you give me a good example of something?" This is a really powerful question for technical people because we, as technical individuals, tend to focus very much on the technical aspects. Sometimes, we're not so good at interacting with people on the business side. Thus, asking a simple question like, "Well, can you give me an example of what a limit of liability is? What does that mean?" is a really powerful way of being able to dig into these domain concepts.

These business terms are often thought to be understood until one has to explain them, leading to the realization that perhaps they don't understand them as well as they thought. Other useful questions include, "What do you mean by whatever that term is?" For instance, "What do you mean by limit of liability? What do you mean by appraisal?" Another insightful question could be, "Why might someone submit this invoice, or what might lead someone to perform this action?" These are all great questions to ask.

Similarly, asking "What else might happen?" is important. Often, when teams are doing this for the first time and they sketch up that series of events, it reflects a happy path kind of situation—here's how it's supposed to work. Once that is established, I suggest asking, "Okay, what else might happen here?" This inquiry can lead to exploring different swim lanes in terms of the map or might reveal that it's a completely different scenario. In that case, we can start somewhere else in the modeling space and see where that takes us.

Now, let me give you some tips for facilitation. I’ve had to learn facilitation mostly through making a lot of mistakes along the way, so hopefully, I can help you avoid some of those. One common mistake made by those who have never run this type of workshop before is thinking that the goal of the meeting is to drive to a decision. Most meetings aim to reach a decision on a specific topic, but that's not what an event storming session is about. An event storming session is really about exploration and learning. While you do converge on things at the end, it takes a different form.

If that doesn’t make sense to you, I’m going to provide a couple of resources for you to consider. I recommend two books: Gamestorming and the Facilitator's Guide to Participatory Decision Making. If you’re only going to buy one of those, get Gamestorming, particularly if you find yourself in the role of a scrum master or focusing on agile coaching. It's an invaluable resource for these types of activities.

In Gamestorming, they explain that every game follows the same pattern. When you're trying to get from a known place (A) to a destination (B), A is known—that's where we are right now—and B is where we want to get to, but it’s a little fuzzy. The goal at the start is to get a bunch of ideas out there very quickly. In event storming, this means everyone gets an orange pad and a Sharpie, and I encourage them to start writing down events and posting them on the wall. The key is to not worry about what everyone else is doing; just come up with ideas and start posting them.

This approach aims to open up the floor for people to diverge and generate a lot of ideas. As we approach the end of the workshop, the focus shifts to what we have learned and converging on our next steps. This might involve using pink stickies to represent questions we have, indicating that we need to take action items on those, conduct further research, or perhaps do some prototyping in code.

The structure of every game we play includes an opening and a closing. At the start, you want to diverge and get a bunch of ideas on the table, and at the end, you want to converge on what we learned and where we go from here. However, there’s a whole middle section that I find to be the more interesting part of the process.

=> 00:36:38

Embrace the chaos of exploration; it's where the best ideas emerge and real learning happens.

Towards the end of the workshop, the idea is to reflect on what have we learned and start to converge on what are our next steps. This might involve using pink stickies to represent the questions we have. We need to take action items on those and perhaps do a bit more research or some prototyping in code. The structure of the session includes an opening and a closing for every game that we play. At the start, we want to diverge and get a bunch of ideas out on the table, while at the end, we aim to converge on our learnings and determine our future direction.

However, there is a whole middle section that I find particularly interesting. In the context of event storming, we often reach a point where we have a few stickies up, and it becomes time to really start to explore. This is the phase where people may begin to feel uncomfortable because it can feel a bit chaotic. The reality is that this feeling of uncertainty is somewhat true; we are in a phase of exploration, and we don’t know exactly where we are headed.

During this exploration, you might say, “I’m going to pick this particular idea and explore this sequence of events,” and then do a little digging into that. Once we feel we’ve gone deep enough, we can shift our focus to another area for further exploration. The goal here is to focus on learning and discovery—to identify what don’t we know. It is often in this phase that ideas start to emerge. Questions arise, such as, “What if we did it this way?” or “What if we approached it differently?”

Sometimes, a domain expert from the business might mention an important concept, prompting us to look at the wall and realize that this concept is missing. We can then ask ourselves, “Where is that concept on the wall?” If it’s not there, we can return to the wall and see what it would look like if we incorporated that concept into our model or timeline.

I find this model helpful for thinking about the exploration phase. It’s important to communicate to participants at the start of an event storming session that we will begin by generating a lot of ideas and then converge at the end. However, there will be a middle section that may feel a bit strange, and that’s okay. If participants have never done this before, it’s important to reassure them that it’s a normal part of the process.

This experience can be likened to any game, such as basketball. There are starting plays, concluding moments, and a middle section where players seem to be running from one end to the other. This middle section is actually the exciting part of the game, provided you understand the rules and how it works.

Now, what are some tips for event storming? Firstly, this process is not about driving to consensus or making a decision. Instead, it is about getting people in the room to focus on learning from each other and understanding the problem domain. To achieve this, I encourage teams to discuss a concrete, realistic business example rather than something abstract. For instance, they might talk about a specific persona purchasing an item online. I would ask questions like, “What item is it?” or “What kind of shoes?” and “How much did they pay for it?”

By drilling into these details, we can identify which aspects are relevant. I often find that it’s easy to discard details that seem irrelevant, but it’s very hard to reintroduce them once they’ve been abstracted away. Therefore, I emphasize that we should not assume we know ahead of time which details are important and which ones aren’t.

Additionally, it’s essential to build on each other's ideas. The collaborative nature of event storming allows participants to expand on what others have contributed, fostering a richer exploration of the topic at hand.

=> 00:40:32

Focus on concrete details to unlock powerful insights; abstraction can hide what truly matters.

In discussing a concrete realistic business example, it is essential to avoid abstract concepts. Instead, let's focus on a particular persona, perhaps someone purchasing a specific item online. For instance, what item are they buying? Oh, it's a pair of shoes. Then, we can delve into further details, such as what kind of shoes they are and how much they paid for them. This level of detail is crucial because, as I often find, it is easy to dismiss details as irrelevant, but it is very hard to reintroduce them after they have been abstracted away. You never know ahead of time which details are important and which ones aren’t.

Another important aspect of this process is the need to build on each other's ideas. When someone writes a sticky note, I like to move people around the wall so they can see what is happening and actually build on those ideas. Related to this is the practice of time boxing these sessions fairly ruthlessly. I ensure that we have regular breaks and provide a rough agenda at the beginning so that participants know how long the session will last. If the energy level starts to flag, I will suggest taking a break.

Additionally, the conversations and examples discussed during these sessions are critical. The timeline allows participants to have something external to themselves that they can look at, talk about objectively, and improve upon. I encourage participants to put things up on the timeline first and then ask questions. I find that many teams get into situations where someone wants to discuss what they are going to write before they actually write it. This can lead to several people engaging in a conversation about an idea that is still just in one person’s head. Without a physical representation on the wall, it lacks a location in the timeline and a description for others to reference.

One of the rules I always emphasize at the start of an event storming session is to post first, ask questions later. If you have a question or an idea, write it down first and put it somewhere on the wall, even if you are unsure of its placement. Then, you can ask the question. This approach allows for conversations about something external, which is a powerful technique, especially for questions. Have you ever been in meetings where someone has numerous questions that lead to rabbit trails? By the end of the meeting, it feels like a waste of time because that person dominated the discussion. This method allows us to use sticky notes to acknowledge good questions and decide whether we have answers right now. If not, we can leave the question on the wall and move on.

As I mentioned at the beginning, I have found event storming to be a powerful technique. It is enjoyable and generates a lot of energy in the room. It elevates the type of domain modeling I care about and enjoy. There are three key benefits I have observed from event storming.

The first is collaborative learning. Having technical people and business representatives in the same room to engage in these conversations is incredibly powerful. It enables everyone to reach a shared understanding surprisingly quickly, which is a significant advantage.

The second benefit is that if you are working in a complex business domain with numerous rules and interactions with legacy systems or third parties, event storming allows you to model that complexity visually. This visual representation facilitates conversations and can be combined with other techniques, such as context mapping from domain-driven design, to explain the situation to business stakeholders.

The third benefit is the high level of engagement observed during event storming sessions. Participants are physically involved, moving around, and there is a palpable energy in the room. The focus is not on structure and form but rather on behavior and outcomes. This focus on events allows for a deeper understanding of behavior and outcomes in a way that other modeling techniques do not.

Finally, I have found that each time I conduct event storming with teams, it leads to better solutions. You cannot create a solution that meets a need without fully understanding that need. Event storming helps to dig into the need, revealing missing concepts and misunderstandings quickly, ultimately helping to avoid rework.