A facilitators recipe for Event Storming

Event Storming is a fantastic modelling workshop for getting shared understanding of a business domain and designing software to match. This is my guide to it

A group Storming around the modelling surface

I started working as a Consulting Engineer in Red Hat Open Innovation Labs a little over a year ago. In this new role the first practice I was introduced to was Event Storming. While at first the process seemed complex, it has become my favourite practice to use with customers. The time taken to break down silos of knowledge and visualise a business process with this technique is what impressed me the most. As a consultant and a developer who sees many clients over a year, getting up to speed quickly with each new client and their unique set of problems is key to being successful. Event Storming (ES) is the technique I use for gaining this shared understanding of how they operate while also visualising their potential issues and solutions.

I am in a fortunate position within Red Hat where I have been able to try Event Storming with several of our customers. Experimenting with what works and what does not work has lead me to write what I think an Event Storming workshop should look like.

A day’s activity at an Event Storming workshop

TLDR;

🚀 Cooking Tips (Some of my thoughts and observations for a successful ES workshop)

• Keep the key / legend in view for groups new to Event Storming. You’ll lose your voice trying to explain each part repeatedly!
• Open with a simple, relatable example. This is especially important for those who do not speak English natively. I tend to use something people are familiar with, such as an online shop.
• Divide and conquer for the initial spine of the Events and let the madness begin!
• Hold off on the Aggregate name until absolutely necessary. I usually create a dummy name such as `combobulator` and put it on the wall. Teams tend to try naming it without fully knowing it. Once you’ve walked through the flow several times you’ll know enough to name it!
• Highlight and visualise assumptions you want to test and ensure they’re carried across to the backlog and tested accordingly. Without needing to add a new colour to the ES, I simply highlight with a dot sticker to denote this is an experiment that needs to be conducted.
• Hold the techies back initially as you’ll end up in the weeds of implementation too soon. This can be draining for non techies and will alter the engagement from the wider group as a result. Watch out for the Dungeon Master as per Alberto Brandolini’s article.
• If you have not got enough wall space use some foam boards as “fake walls” or roll out the modelling paper along some tables joined together.
• ES is a colour puzzle, but some people may not be able to differentiate between the bright colours. Add a simple icon to the corner of each Post-It and to the key so it is clear for colour blind people what each Post-It represents
• The physical modelling space and using tools everyone can interact with (Sharpies & Post-Its) creates a safe space for people to engage with the ES and challenge ideas people present. No tech skills or fancy licensed tooling needs to be purchased to engage in ES. I like to fold Post-Its that are removed and drop them to the ground underneath. The pile that forms represents the misconceptions that have been corrected.
• Space out the spine of your ES or you’ll spend a lot of time moving things along making room for the gaps in knowledge. Never start in the corner with it!
• Mark Pivot Events on the ES and, in big groups divide, and conquer around these boundaries to speed up the process. Ensure you stop and inspect to replay the narrative to all groups at regular time intervals. Rotate to different parts of the Event Storm so all the knowledge can be added when working on it this way
• Map the commands to User Stories when value slicing into a product backlog. When doing this, squash commands that logically fall into one feature. For traceability, a simple id code could be added to the Commands and then imported into whatever tool is used to store the User Stories in the backlog.
• As a facilitator, you have to keep the audience focused. To do this, ask lots of questions to tease out gaps on the narrative. Be sure to include people who may be over powered by loud group members. Just because someone is quiet does not mean they have no valuable input. Some questions I like ask are “How would it behave if something goes wrong?” or “Does this always happen or sometimes happen?”. Reversing the narrative can also be beneficial, “What must happen before this event occurs?”.

What is Event Storming

Event Storming, created by Alberto Brandolini, has been documented on numerous blog sites, wikipedia and youtube so I will not re-create the wheel by describing it all over again.

A full Event storm detailing two customer journeys

My brief description of Event Storming (ES) is it’s a modelling workshop for visualising processes within a business or a system. It gives perspective from all heights of an organisation. For business operation level Big Picture Event Storming can really identify gaps and areas of frustration. Highlighting where tradeoffs exist thus giving your organisation a place to focus on improving. Taking the scope down to Process modelling and through to Feature modelling gives developers, designers, end users and business stake holders a shared language to speak where complicated technological wizardry is not needed. Just a group of people having conversation, discussing the business objectives and capturing things on Post-Its. Inviting the correct people to have a conversation using this visual technique will emphasise dependencies which were previously hidden. Highlighting these can avoid making the wrong decisions about a products from a technical and business perspective.

Event Storming is a pattern for exploration and discovery. It comes from the world of Domain Driven Design (DDD) and I like to think of it as a stripped down DDD. DDD-Lite but with more business focus and less of the jargon complexity. An ES workshop gathers all people from across the business and leaves technical skill requirement at the door. The only requirement of attendees is their energy, attention and willingness to give it a go. During an ES workshop everyone is armed with orange Post-Its (Events) and the knowledge about their part of the company which they bring with them.

Software creation is an exploratory task, and while exploring more learning occurs. Capturing this is critically important. ES is about visualising all that knowledge as an event based mind map and identifying the gaps, unknowns and pain points within. With the right audience for the ES, you can get a harmony between groups who traditionally might never meet and more importantly alignment where previously has been misunderstanding.

For example in an ES workshop you could get the Business Analysts who know the business needs and demands, identifying Commands and Events along side the Developers who will implement the features. Couple this with having the UX Designers and the end users doing some validations of the data and the UI that could support this data and you will get alignment end to end. You will also get early verification of what could work and what won’t before you write a single line of code.

There are a few forms of Event Storming. Big Picture, Service or Process Design and Feature Design. This recipe will cover Process and Feature level design.

For a more comprehensive background to Event Storming, checkout the Open Practice Library where you will find more links, articles and examples of ES being used in the field with our customers.

The things you need for a successful Event Storm

Post-Its. Lots of them. Think of a very large amount of them, then double it. Event Storming uses a very specific colour coded key. It is important to stick to the authors colours as it gives consistency as you move from Event Storm 1 to Event Storm 2.

Energy. Event Storming is an intense workshop that requires people’s attention the whole time. Ironing out misconceptions requires the right people and for them to be able to speak out. Bring the good coffee with plenty of water and fruit!

Space. Give yourself an unlimited modelling surface. Roll out some plotter paper, or if you struggle for wall space use big foam boards that can be moved and added to. You don’t want to constrain the amount of information gathered by lack of wall space.

People. The most important ingredient. Invite the right people. Get your end users, the Business Analysts, Architects, Business Owners, Product Owners. Get all the people. The more you can get the better fleshed out your ES will be. If you do not have the right people the workshop will not be affective.

🛒 I have created an Amazon (UK) shopping list for those looking for a shopping-list-as-code Event Storm experience. 🛒

The things to do and the order to do them in!

Pre-heat your oven

Hack the space. Remove all the chairs from the room and mark a big empty wall space for you to roll out the modelling surface. Chairs lead to people sitting down which leads to people not participating which leads to people falling asleep! Give yourself lots of room and roll out your plotted paper / foam boards. Do not start in a corner, start in the middle of the room if possible. Starting in a corner will mean only 50% of the audience will be able to gather round it therefore removing half of the knowledge being offered.

Bring out the Event Storm Flow. I usually make posters (on large flip-chart sized Post-Its) the night before running the workshop, as this can be time consuming. Hang it so it is within eyeshot of all the attendees. People who are new to ES will want to keep referring to it to guide them initially.

The Event Storm flow

I normally walk through the flow of the ES at this stage with the attendees. This can be fairly overwhelming as a lot gets introduced at once, but more detail will follow. I create and walk through an example based on something fabricated, but relatable to hammer home the point. Usually I will go for either TODO list management or something more tangible such as an Amazon purchase.

Start cooking

With the ingredients all laid out and the oven pre-heated, it’s time to start creating the mixture!

The Event Key

The first thing I do is set the goal of the Event Storming workshop. This could be the entry point of the flow, the end point or both. Introduce the Event poster as with the examples as seen above. In its simplest form, an Event is just something that happened in the past that someone cares about. With the starting point set, ask the attendees to divide into groups of 2 to 3 and identify all the Events they can think of in the system. Time box this activity. I usually go for 15 to 20 mins initially and hover around making sure people are on task and conversing, clarifying things if needs be. If there are SMEs in the groups, I make sure these are divided into the groups equally and not bunched together in one.

• With the team’s Events identified; ask for a volunteer group to play theirs back to the group by adding the Events to the modelling surface and begin telling the story. Enforce the timeline of the events, moving left to right. The first person in a group to volunteer their spine should be rewarded with a gold medal for breaking the ice. I draw a medal on a Post-It and award it to this person so they can wear it with pride. A Top-Tip (🏅) is to not start fully on the left hand side of the modelling space. When things start to get moved around as more knowledge is uncovered this space can be useful to grow into.

The Ice Breaker hanging Events on behalf of her team

• Ask the other groups to add in their Events along the timeline. Encourage the attendees to shuffle theirs along the surface to make room for more Events to follow. If teams come up with different words to describe the same event, try to get consensus on the language. Clarify events that are not fully developed. For example, if a group has a very high level event, such as “Item Ordered” break it down into the lower level detail like “Item Added to Basket” and “Check out opened” etc. If there are any questions or assumptions being made; mark them if they cannot be answered just yet. (🏅) It’s important to park the things that cannot be answered confidently and move on or you can end up in the weeds very quickly. Ensure enough time is given to the discussion in case the answers can be uncovered but if not mark them with a pink Post-It representing the Question. The Question key will be used very frequently initially, as this is the point with the least collective knowledge of the system. When marking an area with the Question we are stating that conversation will not be forgotten and can be returned to when needed. A good idea can be to hold off on revealing this card until enough conversation has been had and it is needed in order to move on. Be sure to capture all sides of the discussion with multiple cards if needs be.

With the spine of events created, have the teams play through the story from front to back and back to front. Add in any missing Events through the conversation that occurs. At this stage I like to mark Pivot Events with some tape coming vertically from a single Event. These can be useful in framing the boundaries between key things and can be great for quickly identifying key sections of the timeline. This can also be a good time to introduce what I call the Helper Poster. It contains all the extra Post-Its that are useful for you Event Storm kit bag such as the Happy and Sad stickies

• The next section introduces the bulk of the keys in an Event Storm puzzle. It’s time to introduce the Actors, Commands, Read Model and Systems. Add the charts for each so they’re within eyeshot. Walk through them with the group and clarify if anyone has any misunderstandings. The Command represents a decision made by a user in response to some information retrieved from the Read Model. The Actor is the person who issues the Command and the System is the thing that receives the Command. It is the responsibility of the System to respond to the Command and therefore trigger an Event. There is quite a lot introduced in this section so it’s important people do not get overwhelmed with the next pieces of the puzzle. It can be handy to go through another simple example if the audience needs something more relatable. I tend to add a few of these pieces to the spine so the example is now in the context of the flow being created by the wider group.

The Event Storm Posters should detail parts of the key with examples

• Teams should now prepare to add the new parts of the flow again! Break into groups but rotate the members. If there are SMEs in given areas, again, make sure they’re distributed within the teams that are formed. Get the groups to come up with the Actors, Commands and Systems that the command is issued to. Time box this to 15 mins again for the first pass. If the volume of events is quite large and the group is too, it can be useful for the teams to take the events between the two Pivot Points and flesh them out. This can speed things up, and all will be replayed together afterwards so the shared understanding can still be achieved. I try to steer groups away from being bogged down on whether the system is internal / external or how it should be named. It’s good to keep things fuzzy until absolutely necessary. For me, the primary thing with the System at this stage is just to identifying that there is a thing which the Command is issued to thus triggering the corresponding Event. In my experience being fuzzy at this stage prevents people falling down the rabbit hole, and keeps the discussions at a high level so all feel included.
• Have the teams replay their additions to the Event Storm to the rest of the group. In doing this, more discussion will be generated and there will be more gaps identified. Capture assumptions and add in the missing pieces as part of this replay. Usually the full ES will not have been updated, but that’s OK. There will be more time to fill it in as we continue to re-tell the story.

Three groups Storming around the pivot events

• If the teams have divided around Pivot Events and more time is desired by the groups to flesh out the flow, I will often rotate the groups to a new section between differentPivot Events, set a new time box and go again. This helps to validate other groups work and also flesh out the flow further with fresh eyes revealing more knowledge
• During the next group replay of the full Event Storm, I introduce the another part of the key. The Policy and Procedure and some more pieces from the Helper Poster such as the Subprocess. The Policy and Procedure is a great way to flesh out some of the gaps between Commands and Events. While the group is replaying the story, asking questions such as “Does this always happen?” or saying things like “Whenever Command we alwaysEvent”. Doing so will tease out small things between the events that have not yet been thought of. I think this is why Brandolini refers to this card as the Lie Detector.
• The Subprocess can be a great way of parking content that will not be stormed during the scope of the workshop, but will be returned to later. For example, a customer I worked with had a process for third party fulfilment but was out of scope for the process they were trying to uncover. The purple Subprocess Post-It was used to denote this unexplored area and was returned to in later workshops. A simple piece of tape was used to connect the two processes once they had been nested beneath each other so the visual connection between the two flows was not lost. A Top-Tip (🏅) is not to use a marker / pen as the flow may move / be removed.

Storming around some of the parked Subprocess

• Branches in the flow will inevitably occur. I mark these in a visual way with Happy or Sad sticker to denote positive and negative sides of the flow. Usually for every Happy there is a corresponding Sad. The Subprocess in my eyes is a great way to capture these without getting bog down into branches of the flow that we are not trying to explore in the scope of the workshop or wish to return to in more detail later. If an Event results in lots of Commands being made available I stack them vertically so the flow can be fleshed out one at a time. If time is tight, it can be good to just pick or two flow to flesh out from this and return to the others later. It’s important when branching occurs to focus on the goal of the Event Storm and not getting bogged down in the weeds with low quality information.
• With most of the puzzle pieces in place, by now the ES should now start to tell a more detailed story. Continue to replay the story forwards and backwards, starting in the middle and going in all directions. Challenge all the items that are there, and don’t be afraid to add or tear up pre-conceptions. You should start to notice the volume of Question Post-Its drop off as the knowledge is added to the ES.
• If the system you’re modelling has UI components to it, a great addon is to include some high level UI’s to the Read Model. Simple sketches on Post-It can quickly validate what components the UI might need as well as validate the data that’s needed for them can be retrieved. If there are end users of the application being designed present, it can be really powerful to replay the ES with these designs to them further validating the hypothesis of the flow.

The group adding UI to the event storm on a Green Sticky

• Finally it’s time to identify and name the Aggregate. The aggregate is the state machine of the system. It’s the thing that receives a command and decides to act upon it or not. I only introduce the System early in the flow as the Aggregate can be the bit that leads to most confusion and be the biggest time sponge - especially naming it! By holding off until the end a large portion of the unknowns are cleared up. When the flow is more fleshed out I get the group to replay the Event Storm and identify where the System is either existing or has to be built. If it has to be built, I add the yellow Aggregate card and give it a nonsense name such as combobulator. By doing so, it helps people not get bogged down in the boundary of where the Aggregate should be defined. Continue to replay the flow and the group will naturally start to identify that some commands are issued to the combobulator and others to something else. Capture these as something else. When a full pass of the ES has been complete, then return to naming it. The depth of understanding should be so high that the name and boundary of the Aggregate should naturally fall out.

Final thoughts

Event Storming is a brilliant technique. The domain knowledge it extracts and the time taken to accomplish it is powerful. It can be used at a business level to identify pain points and areas to improve, much like a Value Stream map. Lower level Event Storming is a great immersive, collaborative process for designing software. I would highly recommend you try it, it’s a tough one to get right but practice makes perfect.

Part two of this post will cover moving from the Event Storm to an Initial Logical Architecture and to a Product Backlog teams can pull from.