Tl:dr: Use Event Storming to rapidly gain group understanding of complex business domains while having a more enjoyable time.

While I was browsing tech news sites looking for articles, a headline caught my eye talking about domain-driven design (DDD). Its main idea was to implement Event Storming to drive the understanding of the business domain. The more I read about it, the more I saw the value in what Event Storming offered.

On a recent consulting project, we were piloting Agile in a Waterfall environment, so in reality, any requirement gathering process used would have been new. We chose to compare Event Storming to User Story Mapping, allotting just one hour to work with each process. The process that the pilot Agile team favored would then be used going forward.

In this blog, I will share the main takeaways and benefits that became apparent while implementing Event Storming sessions, especially as compared to User Story Mapping. I will first explain the project we worked on and underlying opinions that drove our trial, what key aspects of Event Storming stood out to us, and then tips I picked up along the way for effective Event Storming sessions.

Blog Quick Navigate

First Steps: Our Project & Perspective
Key Event Storming Takeaways
Team Evaluation of Event Storming

Event Storming Resources

There are a number of good articles covering the Event Storming fundamentals, so I won’t go over them here. Check out these informative articles to learn how Event Storming works:

• Event Storming – Ziobrando’s Lair
• Facilitating Event Storming – Mathias Verraes
• An introduction to event storming: The easy way to achieve domain-driven design – Steven A. Lowe
• Event Storming Exercise – Tim Schraepen

With the basics understood, what we did find out as a team is absolutely worth covering, so let’s get started!

First Steps: Our Project & Perspective

After getting my own knowledge base established, I wanted to start facilitating some Event Storming sessions. Fortunately for me, the timing worked well to start with a smaller project.

The goal of the project was to implement an existing business process not wholly formalized by software. While the project was considered small, the process was supported by several Excel and Access applications and was not well understood outside of just a few people.

The domain was very event-driven, so the project sounded like it matched up very nicely with the strengths provided by Event Storming. The Agile team was piloting a lot of new technologies, so it wasn’t hard to sell another process that promised delightful benefits everyone would like!

Trying Something New: Comparing To User Story Mapping

I’ve never been a fan of the traditional requirements gathering meetings or meetings that try to formalize a business process. The first meeting is fairly productive since going from nothing to something is easy. The productivity after the first meeting is hard to sustain. Each additional meeting may include a different audience and new languages. The language may be different business dialects or software modeling languages. The different makeup can cause misunderstandings and rehashing of completed requirements.

It doesn’t take too many meetings until people leave exhausted and frustrated. The more complex the business, the more inefficient the meetings are. People’s faces provide enough information to know I’m not the only one who feels this way. So when I read the articles describing the benefits of Event Storming, as an efficient way of exploring complex business domains, I was all-in for trying.

We were piloting Agile in a Waterfall environment, so again, any requirement gathering process used would have been new. On previous Agile teams, a User Story Map was created to help drive out requirements. Creating a User Story Map is a step in the right direction but it still felt a little disorganized.

The issue I have with User Story Mapping as one of the first steps of requirements gathering, is how easy it is to focus on goals that have little business value while missing the high value targets that don’t have a lot of visibility. An individual’s personal preferences can get in the way. There is a lot of fluff to prioritize when there are stickies representing 20 different ways of searching for a product but only two stickies covering what happens when a purchase is made.

I didn’t want to spend time on something that didn’t produce an obvious difference or not have a willing audience.

I was upfront with the team on wanting to compare Event Storming to User Story Mapping. I only asked for one hour to work with each process. If the team favored one process to the other, then we would use that process. I didn’t want to spend time on something that didn’t produce an obvious difference or not have a willing audience. With the team’s great spirit, they were very willing to bring in the frameworks and ideas to create an efficient environment.

Event Storming Takeaways

Informal, Simple and Quick

One part of Event Storming that really was attractive to me was how informal and simple the process is. The informal process helps lower the amount of time needed to start getting tangible information on the board. The quicker people realize progress is being made, the more involved they will become.

Event Storming gamifies domain-driven-design. This interesting makeup encourages small groups to collaborate with each other using low-tech tools. Basically, you get people with questions (developers) and people who know the answers (domain experts) in a room with a bunch of stickies and markers. Rapidly understanding the domain is the goal.

It is not as formal as other DDD practices because it stays above the domain details and a lot of extra technical modeling details are not included. Domain experts don’t really care about the differences between a value object and an entity. The complex modeling language used may not be understood by others outside the modeling world. The domain language on the stickies is concise, precise, and relevant. This allows for anyone who views the generated model to understand the business process described in Domain Events.

It is refreshing how many Domain Events can be added in less than an hour.

To quickly explore the whole domain, Domain Events do not have to be added linearly across the whole timeline. Each slice of domain or subdomain tribal knowledge can be reasoned about concurrently. It is refreshing how many Domain Events can be added in less than an hour. The high and consistent productivity across Event Storming sessions is a big advantage for Event Storming. Productivity doesn’t drop off after the first meeting like a lot of other processes do. It is important to keep the session times short to maximize creativity that gamification needs.

A Focus On What’s Important

Another Event Storming aspect that is appealing is how the focus is naturally kept on what is important. The initial time is spent on determining what the Domain Events are along the business process timeline. A Domain Event describes what occurred in the domain that is meaningful to the domain. In other words, Domain Events are what is important to the business.

The key here is determining WHAT happened, not HOW. With the focus on collaborating on Domain Events, other distractions are kept at bay and the focus can be maintained on the important stuff. Without keeping a proper focus, many discussions diverge and start placing emphasis on the ‘how’. The ‘how’ can be easily brought up due to past technology pain points in order to prevent the pain from being implemented again. Developers love to start talking about the ‘how’. The ‘how’ is important, but it will be figured out after the domain is fully understood.

Stock Price Alert Example

As an example, let’s say a current business process has a team member email several stakeholders when a stock price falls below a certain percentage. This is a very manual process. The team member needs to monitor a stock price, take action when the price changes significantly, and then send out an email to a list of people. That sounds like a pain point. When describing the process using Domain Events, the painful ‘how’ is left out. Instead we can model it by using something like the following.

When we go to implement these Domain Events, the painfully manual steps can now be replaced with an automated process. The prior implementation didn’t taint the Event Storming artifacts on the board.

The Domain Events form the meat of the application. This can be solved with a monolithic application, microservices, or whatever implementation pattern that makes sense. This isn’t saying we are always leaving out the other details that may be implemented in the other layers. They are included only when necessary.

A Domain entity name is included and important in describing a Domain Event but a Domain object isn’t formalized as a Data Model as other DDDs do. A Read Model presents something the user will see. It is included only when the user sees something that will affect their decision.

Like the example above, if the user takes action when a large negative percent appears, then adding a Read Model with a large negative number on it would be beneficial to the model. A user persona or external system helps determine who or what originated the event. Again, we are not discussing how a Domain looks or how an item on a Read Model is displayed.

Group Learning: Slices Become Whole

A complex business domain trying to be understood is usually based on slices of knowledge or tribal knowledge. Business domains are complex enough that one person doesn’t spend enough time in other parts of the domain to truly understand it. A large or complex business domain may also have several subdomains.

After the domain experts add the Domain Events presenting their knowledge, it is important to review the Domain Events as a whole for everyone in order to achieve group learning. Reviewing the whole event timeline helps remove incorrect assumptions in order to create agreements where tribal knowledge overlaps.

On the first pass across the timeline, there will usually be duplicated Domain Events or missing Domain Events around where the domain expert’s knowledge overlaps. This is okay. The duplicates or gaps will allow for the needed discussions to occur to help resolve what Domain Events need to be there and therefore create common understanding. Not having proper communication and consensus on the domain prevents developing an ubiquitous language and is a big reason why projects fail.

On the first pass across the timeline, there will usually be duplicated Domain Events or missing Domain Events around where the domain expert’s knowledge overlaps. This is okay.

The Domain Event stickies on the board should be easy for everyone to understand and reason about. Other than understanding the sticky color legend, the focus will be on the Domain Event text. The model becomes a low-fidelity information radiator to everyone. What the business process is trying to do must be easily understood by everyone and a goal of Event Storming is to get the information out quickly to the group.

Facilitation

For my first Event Storming session, the business process was smaller in scope, so it was easy to keep the meeting size around the recommended size of 8 people. I spent the first 15 – 20 minutes of the session describing what Event Storming is and what it will accomplish. This time included creating a color sticky legend and describing what each color represented.

Since I didn’t know the domain we were going to be modeling, I gave a quick Event Storming example of what a few Domain Events looked like as part of a shopping cart checkout process. This helped to set the target language for each sticky type. It is important that the team understands details like why a Domain Event is past tense and why the Command is not past tense.

I still had some audience members that were very skeptical of the process. When people are used to hours-long training sessions, how can enough information be distributed in 15 minutes for team members to become productive?

When people are used to hours-long training sessions, how can enough information be distributed in 15 minutes for team members to become productive?

To keep it simple, we only started with adding Domain Events across the timeline. Limiting it to only Domain Events helps everyone work on building the ubiquitous language of the domain and to keep the focus on what is important. There is a good chance definitions differ between domain experts where subdomains exist and between domain experts and developers. As mentioned before, have the discussions to create agreements and common understandings.

Even with only the Domain Events on the board, there is still a lot of value reflected on the board. In a short amount of time, a lot of discussions have occurred and a lot of group learning gained. Domain experts will be talking the same language as the developers.

Helps Define The MVP

Once all the stickies are on the board, agreed upon and understood by all, then what is described on the board represents the Minimum Viable Product. If what is described on the board is implemented as a system, then it will provide what the business needs.

Unfortunately, Event Storming can’t help developers on making sure the ‘how’ is correct. I can envision a Dilbert comic strip on this. “What do you mean you didn’t want this as a mainframe application?”

Fits With Agile

A vertical slice comprised of a Domain Event with a Command, Aggregate, Read Model, and User Persona artifacts fits really well with Agile. Using the language on the Event Storming artifacts language translates nicely to a user story. Granted, the Event Storming language is going to be strategic, so the user story points will have higher point values.

As a (Persona)
I want (Command)
So that (Domain Event)

The text from the Event Storming artifacts won’t be a literal copy and paste, but this should help with the idea.

If a Read Model and Aggregate artifact exists, they can help define part of the Conditions of Satisfaction.

If you still want to build a the User Story Map for backlog purposes, is it now a breeze to do so. Already having a good understanding of the domain and knowing the business value of each user story keeps the population of the user story map focused and organized. You know that everything important to the business is fairly represented on the map. The large user stories can then be broken down into smaller pieces.

It also helps to keep scope down since it removes the “nice to haves” from the start. “Nice to haves” can always be added later when the scope of the MVP is more clear.

Helps To Expose Process Weaknesses

The Event Storming model also helps to create a more resilient system. It gives an opportunity with each Domain Event to ask the question “what happens if this Domain Event fails?” We used a bright red stickie If the domain expert has an opinion on what should happen (not the ‘how’ yet) in case of a failure. The question can be asked again later during implementation (now the ‘how’) on how to build resiliency around the Domain Event.

Along with exposing points of failure, testing edge cases can be discovered and documented.

Input To Other Models

What’s really cool about the Event Storming model is that is that it can be an input to other models or processes. I see Event Storming as a replacement for the requirements gathering meetings. It doesn’t replace other models or processes, and it does not replace domain models and architecture diagrams.

I see Event Storming as a replacement for the requirements gathering meetings. It doesn’t replace other models or processes.

The Event Storming model built on a ubiquitous language feeds nicely into a logical domain model. Just start picking the Domain object names from the Domain Events since the names already have the same meaning to all domain experts. The language and understanding already exists, now start adding the relationships and attributes.

As mentioned before, the Event Storming model can be the input to Agile artifacts such as user stories and user story maps. The model can be an input for a UI/UX architect. The model as an information radiator also radiates information to the UI/UX architect and provides an easy understanding of the business process to help drive out what UI patterns are needed to help drive the application UI strategy.

This last project had the luxury of a full-time UI/UX architect. While the UI/UX architect wasn’t a participant in the Event Storming sessions, the architect was quickly brought up to speed using the model as an information radiator.

Event Storming is fabulous as being an input for identifying business process improvements. Most application re-writes involve engaging the stakeholders to rethink what happens in the domain. Business process improvements can be found by Event Storming the current process to establish group understanding of the current process with the domain experts like before. With the current model, instead of producing user stories, ask if each Domain Event still has a business value or if a new Domain Event needs to be added to reflect a change in business direction. The initial current state model will eventually morph into an improved target state model.

Team Evaluation of Event Storming

Even with only an hour to compare Event Storming to User Story Mapping, there was a noticeable difference between the two. The team tried User Story Mapping first and then Event Storming the next day. With the evidence on the wall, the team decided to keep Event Storming to drive understanding and requirements for the rest of the domain. Within a few sessions, the team had a mature model on the wall.

As a bonus, I was able to use the success of Event Storming of the first project to use Event Storming on a second project. The second project was also based on a business process that wasn’t formalized by a single application. The difference in this project was that most of the events were manual steps controlled by one domain expert. If this domain expert went on extended leave, the whole domain would be in serious trouble.

In the end, Event Storming worked out very well to quickly gain group understanding of the business domain. The group understanding of what needed to be done is helping to determine future plans of the business process.

The domain expert approached me a few weeks after finishing the Event Storming sessions and mentioned how much more enjoyable Event Storming is compared to the traditional approach. The domain expert was currently part of another requirements gathering meeting and was not excited about it. That helped validate my own opinion of the value of Event Storming.

What Worked Well

Here are some things I learned that you might try out with your teams.

• To help facilitate a session, you may have to add the first few Domain Events stickies. Then the facilitator can ask “what happens next?” This usually primes everyone to start adding Domain Event stickies themselves.
• When you start adding Domain Events to the board, add more space between the stickies than you initially think. While it is easy enough to move stickies around, you’ll be moving stickies around a lot until the model become more mature. There are always hidden or forgotten Domain Events in the middle of the timeline.
• Domain Events are usually added from left to right on the timeline. To help catch missing Domain Events, also review going from right to left. Then you can ask the question “Are there any other events that may happen before this one?”.
• Schedule sessions no longer than an hour to keep short bursts of creativity going.
• Don’t spend a lot of time on small areas of the model. If you are spending 10-15 minutes on one or two Domain Events, move on and come back to it later. It’s like going to the water cooler. Things become more evident when you temporarily clear it from the brain first.
• For murky Domain Events, use murky language to identify it as something that is not clearly understood and that needs to be revisited later. Product List got FUBAR’d will not be forgotten later.

What I Didn’t Do

I didn’t remove any chairs. One of the Event Storming articles recommended removing all the chairs in the room to help encourage total participation. I wasn’t that bold. 🙂

Conclusion

Event Storming is very flexible as a tool to understanding any complex domain or business question. Event Storming is a not a process that is owned by a role or functional area. You don’t have to be a DDD expert to be successful with it.

Event Storming can also be used to diagnose why a business process isn’t working. It isn’t working because it isn’t adequately understood or there are some major gaps in the business process. Creating an Event Storming model will help expose the gaps with Domain Events, Aggregates, Commands, User Personas, and Read Models.

Based on my positive experience with it, I encourage you and your Agile team to give Event Storming a try.