Introducing Event Storming

Disclaimer: This is the seminal article about EventStorming. This is where everything started, so I think it's relevant to keep the original. At the same time, EventStorming has evolved a lot since I wrote this article, and the format described in this page is no longer my favorite one. In fact, there's not a single EventStorming format, the tool proved itself so versatile and powerful that I perfectioned a few different recipes. I also had to start writing a book about it, which is slowly progressing to completion. As of today, the better entry point to understanding EventStorming potential is probably my presentation 50.000 orange stickies later (which is also available in video) or reading the first chapter of the book, which is available for free. We are also working on a new version of the EventStorming.com website that should organize pointers to the interesting content about EventStorming that many practitioners published.



In the past months I’ve spent some time experimenting with this weird thing. It started like an “Ouch I have no time to draw a precise UML diagram, let’s do this instead” then became a thing called Event-Based modelling workshop that I presented at Italian Agile Day 2012, I later had the chance to do more experiments in Belgium and Poland during Vaughn Vernon’s IDDD tour, and I gathered incredibly valuable feedback and insights. I managed to find a cooler name - EventStorming - just before the whole thing exploded in summer 2013. While I realized there was a lot of value in it, other practitioners (Mathias Verraes, Tom Janssen, Marco Heimeshoff, Yves Reynhout, Tomas Jaskula, Alessandro Colla, Andrea Balducci, Jef Claes, just to name a few) started exploring and playing with the format with amazing results, leading me to the conclusion that this is something more than “just another workshop format”.

What is EventStorming

EventStorming is a workshop format for quickly exploring complex business domains.
It is powerful: it has allowed me and many practitioners to come up with a comprehensive model of a complete business flow in hours instead of weeks.
It is engaging: the whole idea is to bring people with the questions and people who know the answer in the same room and to build a model together.
It is efficient: the resulting model is perfectly aligned with a Domain-Driven Design implementation style (particularly fitting an Event Sourcing approach) and allows for a quick determination of Context and Aggregate boundaries.
It is easy: the notation is ultra-simple. No complex UML that might cut off participants from the heart of the discussion.
It is fun: I always had a great time leading the workshops, people are energized and deliver more than they expected. The right questions arise, and the atmosphere is the right one.

How does it work

Here are the basic steps:

• Invite the right people to the workshop. Ideally you’ll want a large meeting room with 6..8 people, with the right mixture of the ones who know the questions to ask (and which are curious to listen to the answer) and the ones who know the answers.
• Provide unlimited modeling space. Too often complex problems are not properly analyzed because there’s not enough space available to see the problem. Your problem is bigger than your whiteboard, so what? My solution is to hack the modeling space using whatever available (my favorite tool is an Ikea paper roll) to get rid of the space limitation.
• Explore the domain starting from Domain Events. A Domain Event is something meaningful happened in the domain. It can be easily translated into software, but the real value here is that it could be quickly grasped from non-technical people. An event might be the predecessor of the follower of another one. Place all of them on your modeling surface (the convention is to use orange stickies for this purpose) according to a timeline.
• Explore the origin of Domain Events. Some events are the direct consequence of a user action —> represent it as a Command using a blue sticky note. Others are the consequence of something happening in external systems or of the time passing, we’ll use a purple sticky note for them. In some other cases, we’ll have events that will be the direct consequence of some other events. We’ll simply place the two events close together.
• Look for Aggregates. Instead of defining aggregates starting from the code, we’re taking an outside-in approach: the Aggregate is the portion of the system that receives commands and decides whether to execute them or not, thus producing a domain event.

Bonus targets

These are the basic steps of the original EventStorming format. However, you might spot some bonus goals along the way, if the discussion becomes hot. Here’s a list of the possible bonus targets which are worth considering as a rewarding detour from the standard route.

• Exploring Subdomains: some domain experts will show more expertise in an area, leaving other portions of the domain to others. Different areas of responsibility map pretty well to different subdomains or portions of the pork if you’ve been exposed to my presentations in the past.
• Exploring Bounded Contexts: during the discussion, some conflict areas might emerge. Developers and facilitators with a DDD mindset will spot different interpretations of terms, as a trigger for discussion around the meaning. This might be a good moment to draw the boundaries between the multiple consistent models that will coexist in your domain.
• Sketching User Personas: when talking about commands, conversation tends to steer towards the context where the command is issued and the goals of the person triggering the action. This is valuable information, don’t blow it! You may expand the notation to include little yellow sticky notes as personas.
• Sketching Key Acceptance Tests: if the discussion starts revolving around corner cases or ambiguous scenarios, there’s no better way to remove ambiguity than to define a clear acceptance test. Not all scenarios will need to be documented in such a way (I mean not in this workshop, mostly for time reasons) but if they’re a tiebreaker in some areas there’s no reason not capture the emerging knowledge right now.
• Sketching Key Read Model Artefacts: for some scenarios what the users see if far more important than what the system does. If a screen, table or graph particularly valuable to a given user, just sketch it in a sticky and place it close to the command it is associated to.

Below an overview of all the possible the workshop steps, so far:

A better quality image could be seen here

Putting everything together is a lot of stuff. Just keep in mind that the goal of the workshop is to learn as much as possible in the shorts possible time. We invited key people to the workshop, and we don’t want to waste their time.

So, when it comes to these bonus goals, be ready to use time in the most efficient way: you get a valuable hint, just sketch it and place the corresponding sticky in the hotspot. Don’t drive the discussion towards model completeness: the model is going to be huge, completing it might be of little value or even sound scary for some participants.

Embracing incompleteness will make the workshop less boring and more fruitful.

Choosing the right format

As you noticed, there isn’t a single format for the workshop. In fact, the first steps are more or less the same, but the format may vary according to the roles of the participants, and the project scope.

Minimal Scope

I’ve found the results really valuable even when stopping with Domain Events, i.e. we did an EventStorming session in my company exploring the business flow of training classes we are running. Participants were not developers, so the goal was simply understanding the system by asking the right questions. And we did it in a couple of hours. At the end of the workshop, every new hire had a clear idea of what our company was supposed to do.

(In this scenario we used a slightly different notation, that was more meaningful for the participants: Orange —> Events, Purple —> external systems, Blue —> external organizations or communities, Green —> Artefacts). 

When exploring for software development the result is even more powerful. Aggregates, Commands and Domain Events, all map pretty well into software artifacts. You might run the workshop to grasp the big picture really quickly and to provide a physical space where discussion around the flow happen.

Turning the model into code

DDD practitioners like this approach not only because it’s fun but also because the resulting model is a lot closer to what they need: this ain’t no data model. The resulting model is fully behavioral: there is no underlying data model that constraints the implementation against its very nature. If you’re oriented towards Command-Query Responsibility Segregation chances are that after trying the workshop you’ll be experiencing the urgency of offering me a beer.

You can also start coding almost immediately and validate the result of your exploration in code in a very short time. This is what most productive teams do, and the combination of discussion-based discovery with a Domain-Driven oriented implementation can deliver massive improvements.

You’ll be basically implementing the right thing faster.

How do I start doing EventStorming?

Running an experiment isn’t that difficult. All you need is:

• a suitable room, quiet and large enough to contain the modeling surface (if the weather permits, outdoor modeling might be an option too, but the wind might be a major blocker);
• a writable surface, most likely an Ikea paper roll (codename Måla, you can find it in the kids' area).
• a LOT of sticky notes, in different flavors (the basic set is pale yellow rectangular stickies, plus orange, blue, and purple squared ones);
• working markers, ideally one per participants plus backup;
• some masking tape, just in case;
• the right people.
• a facilitator.

You might want to prototype the execution in a sandbox (some User Groups are perfect for that, they love experiments) before involving your Darth Vader-like boss. You might also want to join the growing community of practitioners and experimenters.

Or you might want to hire a facilitator, for a day or two, to run the workshop in your company, while providing guidance about the workshop itself and the further possible steps.

What’s next…

While practicing and experimenting with EventStorming, I realized that I’ve stumbled upon something bigger. I tried to tell the story of what happened in the past month in this presentation. I called Model Storming the more general approach I am now applying, with EventStorming being just the most notable implementation.
More about it will come soon. This stuff is too cool to keep it only for me! ;-)