AI Native Code
Unit 08

8. Event Storming

Let's explore an Event Storming workshop, from preparation through the session to what happens afterwards.

Event storming was invented by Alberto Brandolini. It is a collaborative workshop where people use colored sheets of paper, like Post it notes, to form a model of how an organization works or a business process runs, or to come up with an idea how to capture this model in software.

Watch the 12 minute video

Preparing the workshop

It takes surprisingly little materials and supplies in order to run successfully.

You need:

  • A sheet of paper.
  • Masking tape that will be used to fix the paper to the walls and other surfaces.
  • A chair.

Ideally, that would be the only chair in the room, because event storming workshop is interactive, and we want people to be standing around our modeling surface instead of sitting down in the corner. On that chair we’ll put supplies: Post it notes and markers.

In order to prepare for the workshop, we take our sheets of paper and fix them to the walls. We want to place a legend.

Legend contains descriptions of what different kinds of Post it notes mean for the context of this workshop.

There is a book by Alberto Brandolini. Ideally, all the people who are attending the workshop would at least be familiar with it.

It is not a hard prerequisite. I’ve seen workshops being successful when nobody except for the facilitator knew what event storming is.

Recording domain events

We start by recording domain events, signified by orange Post it notes. A domain event describes something that happened in the past and that is important to the business.

For an online shop, an important domain event could be:

  • The user was created.
  • The user put something in his shopping basket.
  • The user proceeded to the checkout.

The domain events are expressed in the past. When we start the workshop, ideally the facilitator will put a few well known domain events to the modeling surface so that people would not be scared of the big empty flat surface, to avoid writer’s block.

We start putting domain events on the sheet of paper. The general convention is that there is a flow of time. It goes from the left to the right, and people should place their domain events wherever it makes sense for them. It can be messy in the beginning. The order will emerge. It is okay to move Post it notes, to group them together, or put them far.

If we find out that there is not enough modeling surface, it’s okay to start adding new sheets of paper.

Problems, votes and ideas

One more type of the Post it notes that could be used to facilitate the event storming workshop is a problem. It is signified by irritatingly bright Post it note that is fixed slightly off the angle, and it will signify the hotspot. For example, the discussion around some part of the business model can get stuck because people cannot agree on the name or they cannot figure out how to name the domain event.

We can put these markers to tell people that we’re going to get back to that. Since these markers are irritating, people will eventually want to get rid of them and bring everything in good order.

We can use thin strips of blue Post it notes to signify like, or vote, or some support. If everybody likes how domain event was phrased, or everybody thinks that it is very important, writing that domain event over and over again would take too much space.

Event storming process is unpredictable. It can trigger a lot of ideas. People will come with their understanding of how business works, with problems, with ideas. We can offer them to use green Post it notes as potential ideas for improvement of the business or something that they want to be included in the model.

Finding structure

At some point it might make sense to start refactoring. For example, people have a cluster of domain events, and they want to clean it up and organize them better. It’s fine to take them from one sheet of paper and move to a different place and start working on them separately.

As we move forward, some patterns might start emerging. For example, there are three large clusters of the business model on the primary worksheet, and there is a small cluster on additional sheet of paper.

One of the reasons why event storming works so well is that probably people try to synchronize the abstract ideas that they have in their heads with the picture that they see on the wall.

People that have seen the problem from different angles contribute to that model while trying to maintain order. That’s what makes it possible to start seeing a structure in the picture that you see in the end of the single event storming workshop.

Bringing in the right people

You need to invite the right people. You need a facilitator, somebody who is experienced in running this kind of workshops. He doesn’t have to be a domain expert, but he needs to know how to make the flow run smoothly, how to encourage people, how to resolve the problems, and how to prevent writer’s block.

We also invite domain experts, people with the knowledge about the thing that we’re trying to understand and break down. It could be people working from the business, people from the marketing. This could be software engineers, because these are the folks that have tried to distill it in software.

We remind everybody that we’re working on the big picture event storming exercise, where we try to make sense of the entire business. In this exercise we’re talking about the flow of time, and we arrange domain events along the timeline.

Facilitator puts the first couple of domain events on the board to start the process. The people might say, “No, it’s not right,” or, “Yes, I know of one event,” and they start putting their pieces on the wall. When some people start expressing their ideas and shaping the domain, other people that are present in the room would also get their aha moments.

They would realize better how things are working, and they would start putting more Post it notes.

After the workshop

  • When we have a big picture, the next possible step is to iterate. We can take what we’ve learned from this exercise, clean up the whiteboard, or plan to meet next time, and build our model from the start.

  • Another possible way to move forward is to focus on a single business process. This business process can span for the entire business involving multiple teams. We might want to invite these additional people into the room and focus on modeling this business process.

  • Another possible way to move forward from the single event storming workshop is to take a business process that is already clearly understood, bottlenecks are understood, problems are understood, and try to model it in software.

Modeling software

When we’re doing event storming workshop that focuses on software, we’ll be talking in terms of:

  • Actors.
  • User screens.
  • Domain events that are getting published.
  • Commands that are sent from the UI to the backend.
  • Views which contain the projected information from the domain events and are used to help a user make a decision.

Verifying the model

Once we have some solid model, one of the possible ways to improve on that is to verify it. In software world, we usually verify by building a prototype or minimal viable product. This allows us to introduce more people and get more feedback, because we show the model in a different shape to the end users. They might have questions, and this information could be used further to refine the original model.

If at any point we want to refine the model, ideal approach is to clean up all the sheets and start from scratch while keeping all the ideas, all the shared understanding, and potential shapes.

See also Fundamentals.