Event Storming Workshop - A How-to Guide

Master Complex Web Projects with Event Storming Workshops. A brief introduction and guide.

Pioneered by Alberto Brandolini, “event storming” is a kind of brainstorming workshop to map out the events within a domain of software development. It's a workshop-based technique to bring clarity to complex web projects in the context of domain-driven design (DDD). DDD simply means matching the structure and language of the code with the business (i.e. the “domain”) in which it exists.  

An event storming workshop is a highly interactive meeting of the minds, usually with everyone on their feet with a marker, scribbling on sticky notes and slapping them on the wall. 

After a little event storming instruction, you usually have a multicolor array of post-it notes splayed out across a horizontal piece of white paper. It may look chaotic, but it has actually brought the chaos under control—events are laid out in order, paired to their sources, and grouped around questions, concerns, edge cases, and TBDs.

What follows is a quick event storming guide to get you started!

What is Event Storming Good For?

Event storming is useful for:

• Creating a business model for the development project.

• Gain a “big picture” awareness of the product model in all its complexity, highlighting its goals and needs.

• Visualize the product model to brainstorm alternative solutions.

• Find bottlenecks and areas of conflict on mature products.

What is Event Storming Not Good For?

Event storming is not useful as a substitute for:

• UML diagrams.

• Deployment plans.

• Design documents.

• Actual coding.

Why is Event Storming Useful?

Event storming helps in the planning and implementation of complex web projects. It is a fast, lightweight way to map domains from the outside-in. Instead of looking at the domain from a static code perspective, it breaks the domain down to: 

• What actually happens. 

• Why it happens. 

• What has to be in place for it to happen. 

Event storming workshops have at least four participants, but preferably no more than eight to keep the workshop manageable. These participants should usually break down as follows:

• People with questions. Usually the developer who needs to ask questions about how the business practices (i.e. the domain works). It could also be people from different departments who need to understand how their department fits into the bigger picture.

• People with answers. Usually the people who know how the domain being modeled is supposed to work. This could include managers, C-level employees, sales people, support specialists, etc.

• The facilitator. The moderator or facilitator offers event storming instruction, keeps the workshop running smoothly, and makes corrections without disrupting the momentum of the event storm.

For example, for reasons that will become clear later, orange sticky notes contain past-tense phrases. If someone writes a present-tense phrase on an orange sticky, the facilitator might set that sticky at a crooked angle to address later, without bringing the event storm to a halt.

An event storming workshop starts with an open floor, a bunch of markers and multi-colored sticky notes, and a big piece of white paper tacked up on the wall. This is your modelling surface.

The white paper should be vertically oriented, with an arrow drawn across the top from left to right that represents the arrow of time. Sticky notes placed further to the left represent chronologically earlier events; sticky notes more to the right represent chronologically later events. 

Vertical placement of the sticky notes usually doesn’t matter, as long as they progress chronologically from left to right.

Some basic principles of an event storm must be observed:

• The modelling surface should be as big as possible. There may be a lot of events to map.

• Everyone gets a marker. An event storming workshop is collaborative. If the right participants are chosen, everyone will have something to contribute.

• Keep jargon to a minimum. Key participants in event storming will not be software developers; others won’t be domain experts. If need be, a small glossary of key terms can be established on sticky notes at the bottom of the modelling surface.

Now that the modeling surface is in place and everyone has a marker, it’s time to start event storming! Each color of sticky note has a traditional use. You can change it up if you want, but to do the kind of event storming happening in offices around the world, these are the steps of the workshop, along with their corresponding colors ...

Phase 1: The Orange Sticky Notes

Orange sticky notes represent events, or outcomes within the web process. As such, orange sticky notes must be written in the past-tense, as if something just happened. Examples include:

• All tickets sold out.

• Account was created.

• Account was removed.

• Account was deleted. 

A participant usually starts with one orange event sticky in the middle of the modeling surface. It doesn’t have to be the first event in the domain—in fact, it’s usually something in the middle. But it’s a starting point to work forward from and back from.

Phase 2: The Blue Sticky Notes

Once as many orange event stickies as possible are in place, it’s time to break out the blue sticky notes. Blue sticky notes represent commands, or inputs that result in the event. As such, they are usually placed immediately before the corresponding orange card and written in present tense. Examples include:

• Sell tickets.

• Remove account.

• Create account.

• Remove personal/private data from account.

Phase 2b: The Yellow Sticky Notes

Each command needs a commander to issue it, so each command card needs to be linked to the actor who instigates the command.

If the actor is the end user, this is usually represented with a little person or stick figure on a small yellow sticky note, tacked to the corner of the blue card. 

The actor could also be a program, like a queue or continuous integration. 

Phase 3: The Other Yellow Sticky Notes

When you have a cluster of an event, with its corresponding command and the responsible actor, you have a little self-contained cluster called an aggregate. That aggregate can be assigned a name, which is placed above it on a large yellow sticky note. 

Other Sticky Notes

Outside of the basic creation of aggregates, the following other sticky notes can be used to add context and nuance to your event storm:

• Purple sticky notes represent a business process that creates one or more domain events. They may go before an event instead of a command. 

• Pink sticky notes represent external systems which might create a command instead of an actor within the domain. These might precede the blue sticky note instead of the yellow actor sticky. 

• Green sticky notes represent a view, the user’s window into the system to execute the command and trigger the event. The view sticky note may be placed below the command/event pair in the aggregate.

• Red sticky notes or any color you have left over may be used to ask questions, raise concerns, point out edge events, or put a pin in an issue around an aggregate that the team will need to address later.

Although they may look like a chaotic splash of color, event storming modeling spaces are actually a picture of business getting done. With the right participants and a few sticky notes, the different steps of a complex domain come into focus, stocking the participants’ to-do list with actionable steps toward the completion of the web project.

Ready. Set. Action!

Need additional motivation to give event storming a try? Take a look at one of our standout projects where we successfully made use of event storming workshops: