2.3 Strategic event storming

Our definition of ready aligns us for success. It tells us exactly what we need before we can begin event storming:

Before starting

Event storming is a collaborative design approach. The key players — engineers, customers, business experts, subject matter experts — map facts that have happened: events, the commands that trigger them and the state they change. It distills the business to what actually matters, drives shared understanding and steers the team clear of premature technology decisions.

Alberto Brandolini — the originator of event storming — describes three levels of depth: Big Picture (whole-product scope, wide audience, high-level flow), Process Modeling (mid-scope, drill into a specific process) and Software Design (narrow scope, engineering-led, technical artifacts layered on). This chapter covers Big-Picture and Process-Modeling event storming; the Software Design level is 3.4 Tactical event storming. Naming which level you’re at keeps scope, pace, duration and audience calibrated.

Finish 1.4 Business capabilities & functions and 2.2 Roadmaps & OKRs before starting — you’ll need artifacts from both. The companion blog post My formula for running a successful workshop pairs well with this chapter since event storming is workshop-heavy.

The event storming workshop guide operationalizes this chapter step-by-step — use it when you’re ready to facilitate.

Guide to event storming

Event storming is only effective when all the right parties are actively involved. For most event storming workshops you’ll want the whole team there. This is about creating deep, shared understanding. There may be a few situations where a smaller group is appropriate, especially on a larger project where different team members focus on specialized features.

You’ll also want your key stakeholders present: Subject matter experts (SMEs) that know the inner workings of the business. The team, the product owner, even most end users won’t have the depth of understanding needed. Only subject matter experts can design against the right constraints and tell us what the business actually does at a fine-grained level. Your SMEs are also needed so that we can validate important business decisions.

The size of an event storming workshop is controlled by focusing on a reasonable increment of work. Don’t model every feature of a complete system — instead, the scope should be bounded. What you choose to build should align with the priorities you established previously, in 2.2 Roadmaps & OKRs. Ideally, identify an interesting set of features that provide value to the customer and can be developed independently.

You’ll want to plan enough time to fully explore each of the use cases. Generally, about a half-day workshop is very effective. Try to avoid dedicating more time in one session, though: It can be exhausting. Most often, I like to book a two hour working session, some time for a break or lunch, and then another two hour session.

Inputs

• At least 1 to 3 customer journeys.
• Sufficient use cases to fulfill each user journey, grouped by functional area.
• Key results for each use case — specific measurements to validate successful delivery for each user journey.

The three artifacts

Three canonical artifacts make up the event map. Keep them visible throughout the workshop:

• Events (orange) are statements of fact about something that has already happened. For example, “funds deposited into account,” “customer changed address,” or “balance paid.” Events are always stated in past tense — the discipline is what keeps the team discovering rather than designing.
• Commands (blue) are triggers that cause events. For example, “apply for an account.” Commands are the decision points in the system.
• State (green) — or “persisted data” — is noted when a command results in stored information changing. State appears under a command, never under an event.¹

These form the basis for your technical design — the goal is to make sure every stakeholder notes the events that matter, and what information is stored leading up to those events.

Hotspot cards

Pink cards capture unresolved questions — open ambiguities the team or SMEs can’t answer on the spot. An event map without hotspots usually means the team is pretending it knows more than it does.

The event storming workshop covers the mini-legend, the optional fifth color for external-system events and the discipline of not answering hotspots in the room.

Protecting workshop value

Event storming is tricky to run well. Three guardrails matter most: all the right parties must be present (reschedule if a critical SME can’t make it); protect the ubiquitous language by pausing to translate jargon the moment it appears; and every participant must contribute — the facilitator writes nothing but the legend.

Process

Prepare

1. If this is the team’s first event storming workshop, prepare a simple practice session and dedicate 30 minutes to practice and Q&A. Pick a topic that isn’t related to your business domain, so the team doesn’t start diving into design or discussion around the actual work. Keep the tutorial in “tutorial land.”
2. Send the user journeys and use cases that you’ll be discussing ahead of time. If you aren’t sure which user journeys you want to cover, at least offer some guidance. Send those that you think are likely candidates, and include some “stretch goals” in case you have time.
3. Make sure everyone has quick and easy access to your collaboration space. In a physical space, I like using the walls — event maps can get really big, really fast. In an ideal world, you can leave the event map on the walls. The team will come back, modify, consult, revise, and use it as a reference throughout the project. If you are using a virtual space, make sure everyone has access ahead of time.
4. Use a long wall with sticky notes and non-permanent markers in person, or a Miro board pre-populated with the legend and ubiquitous-language dictionary remotely. The workshop guide lists the full materials.

Execute

Run the workshop in three layered passes — events first, then hotspots, then commands and state. The workshop guide covers each exercise with timing, watch-fors and worked examples; the high-level shape is:

1. Identify core events. Chaotic exploration first (orange stickies, simultaneous, no order), then enforce the timeline. Past tense throughout. Pick a single user journey to explore and break it into use cases — one event map per use case if they’re not closely related.
2. Capture hotspots. Pink stickies for every question the team or SMEs can’t answer on the spot. Park them — don’t try to resolve them in the room.
3. Add commands and state. Blue stickies for the trigger of each event, green stickies for what got recorded. Not every command produces state — a “log out user” command may not write anything; “save loan application” clearly does.

The example use case the figures below illustrate: “Sally (Borrower) buys a new bike from Peloton (Merchant) and chooses to pay using installments. MyBank receives Sally’s loan application, approves the purchase and pays Peloton.”

We haven’t included technology choices in any of our design work — and we shouldn’t. The goal is to explore how the business and product works, not how we are going to build it. That comes later.

If we followed our rules, we will have stuck to a single ubiquitous language. Everyone will be talking “business talk,” and everyone in the room will have a solid understanding of how the business operates. If we successfully avoided talking about technology we won’t be constrained by arbitrary limitations. Our design should embody the ideal way the product will work.

Outputs

• Event maps for each user journey. A visual representation of commands, events and state that describes how the system records facts that have happened in the past.
• Ubiquitous language. Agreed-upon terminology everyone uses in all aspects of the design and development process.
• Hot spots. A list of “hot spots” or questions that still need to be answered during future design sessions.

You may be looking ahead to tactical event storming already — taking the event map and adding even more fidelity, crossing the boundary into technical design. We will get there, but there’s value in staying at the customer and business level for a bit more. In the next chapter, we’ll start to separate our user journeys and use cases along business domains — or, the contexts that logically group like functions with like.

Keep in mind that your strategic event maps are part of a living design document. You and the team will add to them, refine them, and invent new ones. That’s fine — just keep an eye on your roadmap and priorities. Stay focused on what matters most to your customer in the upcoming iteration. Anything else — make a note of it, put it on the backlog, and move on.

Further reading

• Alberto Brandolini, the originator of event storming, wrote an in-depth blog post on Remote Event Storming — worthwhile if you’re running a virtual workshop.
• More background at EventStorming.com, including books, featured articles and presentations.²

Templates

• Strategic event modeling template
• Workshop invitation template

Next activity

• 2.4 Domain modeling