Big Picture Event Storming - mastering chaos

Chaos is considered the primordial state or the first condition of the universe from which everything else originated. The sentence “At first Chaos came to be” from Hesiod's Theogony perfectly describes this concept. Despite its mythological origins, it accurately describes phenomena that surround us.

One example is the beginning of the Big Picture Event Storming workshop. It starts with a chaotic exploration, where everything is new, disordered, and likely not well understood. Then, as the session progresses, participants gather more knowledge about the processes or domains being workshopped, and the chaos is gradually organized.

In this article, I will describe how my colleagues and I started organizing chaos during our first Big Picture Event Storming session, where we modeled the device inventory process. If you are starting to read this series from this article, I recommend going back to the introductory post, where I described this Domain-Driven Design project, our motivation for it, and what we aim to achieve. This will also provide you with a better understanding of the process we are working with and the participants of the session.

Check all the articles from the series:

• Domain Driven Design: A SoftwareMill Way
• Mastering Chaos with Big Picture Event Storming
• Finding the Gaps with Big Picture Event Storming
• Event Storming from a non-technical domain expert perspective
• Big Picture Event Storming: Simple Workshops, Big Benefits for Your Business
• Managing complexity and uncertainty in Software Development: know when to press pause
• Remote Event Storming challenges from a facilitator's perspective
• Advanced large-scale DDD

Before it started

Ice breakers

Before the chaotic exploration phase of the session begins, it’s usually a good idea to take some time to introduce the participants and engage in an ice-breaking activity. This helps people feel more comfortable, as they get to know who they will be spending the next few hours with and adds an element of fun to the group. A brief round of introductions from each person is usually good enough for introducing folks.

For remote sessions, it can be challenging to employ well-known icebreakers, such as demonstrating the correct way to peel a sticky note. However, it’s still beneficial to propose some activities to attract the people’s attention. For example, asking everyone to share their favorite movie or the most delicious meal they've ever had. This relaxes the atmosphere of the meeting and brings people closer together, especially if some short, interesting discussions arise during it.

In our case, since we know each other inside out, we could skip this part and proceed directly to the first phase of the Event Storming session

The goal of the Event Storming session

The goal of the Event Storming session should be also set and clarified at the beginning before we start brainstorming. A session without a goal doesn’t make sense. Doing Event Storming is not a goal by itself. It is merely a tool that we use to achieve one.

Our primary goal was to map the current state of the device inventory process. We wanted to delve into the details of how this process truly functions. Thus, we concentrated on its current operation, and intentionally skipped potential improvements for now. Gaining this knowledge will eventually help us in creating the domain model while developing a system that adequately supports this business process.

Mapping the current state is a common goal for Big Picture Event Storming since understanding the present situation is a starting point for further discussions. However, this type of session can pursue other objectives as well, including:

• Identifying pain points and bottlenecks in the process
• Exploring new features or services
• Aligning on a strategic direction
• Improving collaboration and understanding
• Planning and prioritizing work
• Estimating work

It’s all about the domain events

Before diving into our chaotic exploration, let's also cover some theory to introduce the most crucial building block in Event Storming which is domain events.

The process starts with a blank canvas on Miro. It’s the moment to enrich it with meaningful information. Yet, the question arises: what defines "meaningful information"? Our focus lies in gathering the relevant domain events that unfold within the workshopped process.

“Relevance” is the magic word here as we will eventually use those domain events to build the domain model. However, we try not to bog down the domain experts with it. So, the facilitator simply asks everyone to yield all the domain events that pop into their heads. We will sort them out, get rid of any duplicates, and tidy everything up later.

Event Storming defines a set of building blocks, each represented by sticky notes of different colors. While adhering to these color codes isn't mandatory, it's an unwritten rule to follow the common standard for ease of transitioning from one session to another. I'll be revealing these building blocks as we progress through the session.

The first one, and the most crucial building block is the mentioned domain event. Events are represented by orange sticky notes which serve as the fundamental elements for defining the domain events that occur within the process.

They should be written in the past tense, however we don’t force the domain experts to do that at the beginning of the session. This is to avoid blocking their creativity due to the stress related to the form of the event. There will be time to tweak and polish it later on.

Sample domain events

Phase 1 - Chaotic exploration

Chaotic exploration is the initial phase of an Event Storming session, where the primary objective is to surface as much information as possible without the constraints of order or structure. This phase embraces the inherent complexity and messiness of real-world processes, allowing participants to freely express and document their understanding of the system under discussion. This is the phase where divergent thinking takes place which is used to generate creative ideas by exploring many possible solutions. In this phase, we mainly use orange sticky notes to mark the domain events.

Brain dumping

Mateusz, our facilitator, explained everything we needed to know about domain events. He even popped an example event on the board to show us how simple it could be and created a legend of building blocks for us to refer back to. It was definitely a good time to start letting those events flood out of our brains.

He set a 20-minute timer on Miro to give us a bit of structure - not that it was a do-or-die deadline, but more like a gentle nudge to keep things moving. Part of the facilitator's responsibilities is to keep an eye on how the participants are doing and the vibe of the session. Based on the observation he can give more time or wrap it up as initially planned.

Everyone found their corner of the canvas and began to throw events at it. Roughly 15 minutes in, the board was already full of orange sticky notes:

Miro board after the chaotic exploration phase, CLICK to preview on Miro

As you can see, things are quite messy and unordered. Some of the sticky notes are not even in the correct tense. They're filled with abbreviations that might be secret codes to some of us. Others are packed with so much information that they are like mini novels.

But, as I mentioned before, this is all part of the plan. We are in the divergent thinking phase here. The last thing we want is for anyone to stress about making their events look perfect right now. Our main goal was to get as many events - or things that kinda resemble events - thrown as possible. We wanted to grab ideas and insights on the process from every angle we could. And that's exactly what we've achieved.

Now it's time to start organizing this chaos. That is what we tackled in the second phase of our first Big Picture Event Storming session.

Phase 2 - Timeline enforcement

This emergent phase of the Big Picture Event Storming workshop is all about bringing some much-needed clarity and order to the creative chaos we created earlier. We're diving into the events we came up with to ensure everyone is on the same page about what each one means. This phase includes also getting rid of duplicates and sorting the events out.

This crucial step is where the collective brainstorming and divergent thinking of earlier sessions are polished into a coherent narrative that respects the chronological flow of events. It is also a good time to raise any confusion, the things that we are not certainly sure of, or the risks that we observe in the process.

Getting the timeline right

We kicked this off with a 40-minute block. Mateusz took the lead, attempting to sort the events by discussing each one briefly. This chat helped ensure we all grasped what each event was all about. Sometimes, we had to tweak the wording to make more sense or rephrase the events that were either not in past tense or just too wordy. We also didn’t hesitate to remove the duplicated events.

The goal was to get each event placed in the right sequence on the board. Sometimes it was tricky, as not all the events were clear to everyone. We had a couple of longer discussions that involved both modelers and domain experts.

This is why this phase stretched beyond our initial estimate. Mateusz had to add extra time more than once but he was always tuned into our vibe, suggesting breaks when the discussion's flow or our energy levels called for it.

Spotting the hot spots

There were moments when our debates didn't seem to lead anywhere conclusive. That was a time to introduce so-called hot spots. It’s another key building block of the Event Storming workshop that highlights where we are stuck, facing issues, lacking knowledge, or encountering risks.

Hot spot is usually used to mark the event that we are not sure about, and can't find a satisfying answer during the session. It often means we need to seek insights from folks not in the room. Addressing a hot spot usually happens after the current session wraps but before the next one starts, to ensure that the blocker is released.

We typically use red or pink sticky notes to flag these hot spots, making them highlighted as areas needing extra attention.

Sample hotspots

Wrapping it up: The final look

This is how the board looked like at the end of the first Big Picture Event Storming session:

Miro board after the timeline enforcement phase, CLICK to preview on Miro

You can see that the events have pretty much found their order. We've tweaked the wording to better express the essence of each business event. Compared to the initial chaos, it's looking way clearer now.

There is only one hotspot that we couldn’t clarify at this stage. This is because we had our domain experts - Małgosia and Joanna in the session, and they cleared up most of our doubts. From what I've seen in the past, it's more common to end up with a bunch of red or pink sticky notes, especially if we work with complex business domains.

You might have noticed we have introduced some new elements: yellow sticky notes, arrows, and dotted-line areas. The beauty of Event Storming is its flexibility. It doesn't box us into using only a set list of elements. Event Storming is all about supporting our exploration, not limiting our creativity.

Even Alberto Brandolini, the inventor of Event Storming, said that this is like a pizza. There's a basic foundation (pizza’s dough), but the toppings – our modifications and additions – are entirely up to us. Thus, this is perfectly fine to introduce the elements that help us reach our objectives.

In our case, we used yellow sticky notes to highlight some crucial facts that could easily fly off our heads, like underlying reasons for needing a device. The arrows helped us map out alternative paths or places where the process branches off. And those dotted lines? They were perfect for visually separating emerging subprocesses that popped up during our discussions. We initially pinpointed the following sub processes within our main process:

• Device replacement process
• Device service process
• Decommissioning process
• Selling company device
• Invoice accounting process
• Warranty period expiration

From the picture above, you can see there are connections between the first four processes and the main process of supplying the device to the contractor. The last two processes stand apart more. But this is just our initial understanding. We'll dive deeper into this in our next session.

Outcomes of the first Event Storming session

After nearly five hours of intensive discussion, we were all quite exhausted, yet excited and with a shared sense of accomplishment. But the question is: did we really achieve the goal that we set at the beginning of the Event Storming?

The answer is: partially. We've only navigated through the first two phases of the Big Picture Event Storming so far. However, for sure we all understand this process much better than 5 hours ago. We've ironed out the terminology used throughout the process that is a foundation for the ubiquitous language, and uncovered some hidden aspects that weren't immediately obvious. Most importantly, we've all gained a deeper understanding of how things truly operate.

This was a good base for the continuation of this session. At this time we’ve already set the date for the next workshop, where we plan to dive into the reverse-narrative technique. This approach will help us find any gaps in the process. We also want to identify the key actors and systems involved.

We will be covering this and more in my upcoming articles. These will show how the second session unfolded. We’re also preparing a Q&A session with Małgosia and Joanna (domain experts) to get their opinions and insights about this workshop. So, keep your eye on it.

Reviewed by: Michał Ostruszka

Check all the articles from the series:

• Domain Driven Design: A SoftwareMill Way
• Mastering Chaos with Big Picture Event Storming
• Finding the Gaps with Big Picture Event Storming
• Event Storming from a non-technical domain expert perspective
• Big Picture Event Storming: Simple Workshops, Big Benefits for Your Business
• Managing complexity and uncertainty in Software Development: know when to press pause
• Remote Event Storming challenges from a facilitator's perspective