Event storming is a collaborative brainstorming technique used to identify domain events. Event storming can be used as a precursor to more in-depth domain modeling exercises, to assess the team’s current understanding of the domain, and to identify risks and open questions in an existing domain model. Event storming is described fully in Introducing Event Storming: An Act of Deliberate Collective Learning [Bra17] by Alberto Brandolini.

Event storming helps teams better engage with subject matter experts who are knowledgeable about the domain but may have trouble pairing with developers directly. Event storming accomplishes this in two ways.

First, the format requires active engagement from all participants. Subject matter experts have no choice but to inject their knowledge into the process. Second, event storming encourages participants to be concrete and specific. If you have subject matter experts working with you, encourage them to describe their jobs and expertise in gory detail.

Benefits

• Visualize learning opportunities and facilitate a structured conversation about the domain.

• Uncover assumptions about how people think the system works. This allows you to identify misunderstandings and missing concepts.

• Create a shared understanding of the problem and potential solutions.

• Produce a highly visual, tactile representation of business concepts and how they relate.

• Enable diverse viewpoints to be represented.

• Allow participants to quickly try out multiple domain models so they can see where those concepts work and where they break down.

• Focus on concrete examples, not abstract ideas.

Activity Timing

An initial event map can be created in 30--45 minutes. Workshops should run at least 90 minutes to allow for setup and reflection. It’s often useful to allow additional time to try different domain models.

Participants

Subject matter experts knowledgeable in the problem domain must participate. A few members of the development team should also participate to take advantage of the learning opportunity. If knowledgeable subject matter experts are not available, the workshop may not have great outcomes.

This workshop can be run with as few as 2--3 participants and as many as a dozen or more, depending on the workspace and facilitator’s experience.

Preparation and Materials

• Large roll of paper, tape, lots of sticky notes (at least six colors), markers.
• To prepare the room, tape the paper to the wall to create a large workspace. Remove any impediments such as tables or chairs that might prevent participants from accessing the paper.

Steps

1. Before the workshop starts, verify that you have the right mix of participants from both technical and business domains. If you suspect the combination of stakeholders is not right, it’s better to postpone the workshop.

2. Start the workshop by sharing the goals for the activity. You might say something like, our goal in this workshop is to create an event map for the Hamster Production Line system.

3. Introduce participants to the idea of domain events and describe the different kinds of events to be mapped. Assign each event type a color.

   Domain event (orange)

   An event relevant to domain experts that happened in the past. Domain events might be a step in a business process, scheduled, or happen as a result of another event.

   User command (blue)

   An action initiated by a user. Record who the user is on a yellow sticky note next to the command.

   External system event (purple)

   Events that originate from an external system. Record the system on a yellow sticky note next to the event.

   Passage of time (green)

   Indicate how much time has passed when time is relevant to the flow of events.

   Consequences (white)

   An observable change in the business process that directly resulted from an event.

   Questions, comments, concerns (pink)

   Discussion points that a participant wants to raise. Capturing issues and deliberation on a sticky note instead of talking about it encourages participants to continue moving forward, avoids analysis paralysis, and creates a visual indicator of potential trouble spots. Help participants to use this information to address issues during the workshop.

4. Set expectations for participation. Explain that all participants are expected to contribute and encourage participants to favor creating a sticky note over discussing whether or not a sticky note is required.

5. Make sure everyone has a marker in hand. Have everyone write down an event. The facilitator should place the first sticky note on the paper. Placing the first sticky note signals that it is OK to get started. Once the first event is on the wall, the activity has officially begun.

6. Participants place events in the order they occur from left to right. As the group discovers new events, move sticky notes around to make room. Add subflows underneath the initial event with more detail.

7. As the activity progresses, the facilitator should review events and look for issues. An event might take place in the future instead of the past or be abstract instead of concrete. As you find events that need help, rotate them a quarter turn so they look like a diamond on the map.

8. Encourage all participants to work at the same time to build the map. Help participants find areas where they can contribute. Point out hot spots or areas they should review. A smooth-running workshop will appear slightly chaotic to an outside observer.

9. After 15--20 minutes or if you notice participants winding down, encourage the group to review the map and revise events as necessary.

10. Once time has expired, discuss the map as a group. Are there concepts that seem awkward or still in need of refinement? Are there gaps or major questions in the map?

11. Take good pictures of the map. Move it to a different wall. Tape a new piece of paper. Build a new map but change the rules slightly so that the group explores the domain differently. For example, remove a central concept that appeared in the first map, encourage participants to be more specific, or build a new map in silence to try to expose ideas that didn’t make their way to sticky notes.

12. To close the workshop, ask participants to share one or two things they learned during the workshop.

13. Post the maps in a common area if possible. Save the pictures and written notes. Use the lessons from the workshop and the created maps as inputs for other modeling activities.

Guidelines and Hints

• Include a diverse group of participants and ensure your have the right mix of participants before starting. It is better to cancel the workshop and try again with the right mix of people than attempt the workshop without knowledgeable business experts. With only developers present, you’ll get a technical model. With a mix of developers and business experts, you’ll create a visual flow of events, which is what you want.

• Ensure everyone has easy access to sticky notes and markers. Bring more than you think you’ll need.

• Do your best to create an unlimited modeling space. Choose an appropriately sized room with a large wall. Bring plenty of extra big paper. If you’re using a whiteboard, it should be big.

• Explore real, concrete business examples. The more specific, the better. This helps expose new events and edge cases.

• Post a visual legend of the sticky notes being used.

• Ask clarifying questions throughout the workshop. What is a good example of …? What do you mean by…? What else might happen here? The conversations that happen when asking these questions are extremely important.

• Encourage participants to post sticky notes first, then talk about ideas.

• Time-box the activity to encourage the group to move forward quickly.

Alternatives

The general organization of the workshop is similar in nature to User Story Mapping [Pat14].

Event storming can be modified to include different experts and emphasize different modeling outcomes. Here are some ideas from Brandolini:

• Focus on big picture ideas and include many stakeholders when starting a new system or project.

• Dig into specifics required to implement event sourcing^[38] or CQRS^[39] systems by focusing more narrowly on a specific topic area.

• Include user experience experts and overlay a user’s journey onto the event map.

• Use as the basis for evaluation to identify areas of the system that may need to be expanded or can be refactored.

• Run a workshop with new teammates and stakeholders to teach them about the problem domain.