Event Storming is a technique that uses post-it notes to map out a business domain. Alberto Brandolini initially used it as a means to identify aggregates in the context of DDD. Unlike other techniques accessible only to specialists (e.g. UML), Event Storming is easy to understand for everyone: the activity is in fact performed collectively between business and technical people. This accessibility has seen Event Storming being used beyond its original purpose e.g. to discover new avenues for business and onboard colleagues to a team.

Having read about Event Storming for a while, a few colleagues (Shakeel, Ahsan, Abdullah and me) attempted to get our hands dirty by organising a kata activity at our workplace.

Preparation

  1. The four of us formed a small team to organise and facilitate the session. None of us had prior Event Storming experience.
  2. We read a few facilitation guides that we found on Google.
  3. Saw a couple videos each such as a recorded demo and Alberto’s famous “50,000 Orange Stickies Later”
  4. Did a trial run amongst ourselves for our own familiarization. The trial run was conducted on Miro as we were distributed across two locations. The actual event was conducted physically (in person) at each location.
  5. Prepared a handout to distribute to participants. It contained the what, why and how and was generated by AI for the most part. The handout PDF can be found here.

Format

The event started with a 10-minute pitch explaining the what and why of Event Storming. The activity was scheduled for two hours. Participants organised themselves around a facilitator, and each facilitator led one group. Groups pitched a few topics internally before picking one to do the activity on. The facilitator then guided through the process.

Event Storming Steps

  1. Everyone independently or in small groups (e.g. pairs) thinks of “Events” that can occur and writes them down on a post-it.
  2. The events are arranged by time and duplicate events are removed.
  3. Details such as commands, policies and personas are added.
  4. Draw bounded contexts.
Start refactoring from the deepest branch

Learnings

  • For the purpose of kata (i.e. learning), a hypothetical problem that everyone understood worked well as it enabled everyone to contribute with events and other details. Example: a P2P Payments App.
  • We started with a group of 5 or 6, but it grew to 10+ as people joined. We split into two subgroups so everyone could contribute. One subgroup worked on the sign-up flow, the other on the payment transfer flow. Later we stitched the two flows together.
  • Stitching together the work of two subgroups revealed some interesting insights: modules that could be reused, naming that could be made consistent (e.g. one subgroup used “user” while the other “app user”)
  • We had a product manager and design expert in the group, however one the engineers acted as the business owner as they had pitched the business idea. This setting also worked well – we don’t necessarily have to make the PM the business owner.
  • We started a little late, but still managed to end on time (retro included) especially since the group had self-organised into 2 subgroups to map out the flow.
  • For retro, we went around the table and asked everyone to share their learnings (sadly I forgot to note them down). It went very well, everyone had something unique to say.
  • The group was mostly functioning on it own, the facilitator just had to explain at each new step what to do (e.g. “start adding the policies, personas etc.”). Most of the facilitators time was spent onboarding late joiners (using the handout as well as a 10-minute pitch)
  • Post-its were not sticking to a glass wall, something we should have tested before the session. We ended up using a table for the activity (instead of a wall) and that worked pretty well. Also need to learn how to pull post-it from the stack without bending them.
  • There should be at least 1 marker for each per person and lots of post-its so there isn’t a bottleneck on supplies.