About 15 months ago I participated in an Event Storm masterclass in Milan with Alberto Brandolini. This post assumes you already know what event storm is and you’re interested in reading about usecases.

Let me start with a foundamental premise. What I like of event storm is how collaborative it is. When I see a facilitator doing all the work in an event storm it’s really hard for me to be politically correct and say “you’re doing it differently” what I wanna say is “you’re doing it wrong”..

Granted there might be scenarios where the facilitator wants to speed trough the process but the power I’ve seen in event storm is when the group discovers and communicates to create a shared picture. If a facilitator is the only one adding information then event storm isn’t much different then a service blueprint.

In the last 15 months I’ve run multiple event storms here’s a few use cases with pro and cons.

Internal training

I did a 2 hours internal training event storm to “learn how my company works while practicing event storm”. As Alberto did in the masterclass I kept instructions at a minimum and threw all the participant in the water.

• People: 15 (from 5 divisions)
• Pro: people got to learn more about other parts of the company. Easy to contribute domain events without needing to setup role-play.
• Con: the large org (3K ppl) meant there was a lot of details. See photo.

Project kickoff + future state

At a project kickoff I run a 4 hours session with a small company ~10 people to walk us trough their current processes. As the project went on we used event storm to visualise the future state.

• People: 3 (CEO, Director of Underwriting, Director of Sales) ~3h
• Pro: All client folks aligned on where the hotspots are. Contractors ramped up pretty fast on the domain.
• Con: CEO wanted to fix everything. It took some tries to start in one spot. We didn’t have CEO or Sales director for Future state exercise which created misunderstandings.

Scoping of work

A client scoping to understand their current process and their priorities for a subsystem to add to their processes.

• People: ~6 on their side (3 divisions) ~2h
• Pro: gave contractors a good return on time invested to create a next steps proposal.
• Con: unclear what systems/events were there and which ones were future state. For mitigation, I asked to mark the future state with a black dot on the top right.

Sharing domain expertise to rampup devs

A client that worked in a domain that contractors were not familiar in–contractual bonding–shared the business flow. * People: ~10 client + contractors ~2h * Pro: the two domaine experts shared information and folks with partial knowledge

Conclusions

I see event storm as a tool to design for emergence.

Its final result is a snapshot in time and context. It’s a snapshot of the current understanding of the system or subsystem we’re looking at.

I did take photos of the outcome to document the process but I kept reminding everyone present we shouldn’t consider the outcome as a golden document.

We should be able to recreate it. Probably not alone.

In my experience it’s been a useful tool to allow groups to gain a shared understanding on a system and align on what to takle first.