Event storming for getting up a team up to speed
Team velocity improves when we have a shared understanding of the problem.
You're tasked to kickstart a new feature or project. Perhaps it is vaguer than that; 'have a look into this area and fix it!'. We must understand the current state and requirements for the ideal state we want to build. You start talking with stakeholders: product managers, subject matter experts, legal, and long-time engineers. Chances are that you learn that each stakeholder understands the problem differently! Person A says the problem is X, but person B says the problem is actually Y. Different vocabulary is used, or more confusingly, the same terms are used by different people to mean different things. We know we need some workshops to get everyone on the same page, lest the project be a disaster. How do we run workshops, ensuring people from all walks of life with different technical and process knowledge remain engaged?
Enter Event storming - a workshopping technique for helping cross-functional groups explore complex business domains. On a (lot of) whiteboards or butcher's paper, the group builds up a visualisation of:
High-level processes in the domain you're investigating (e.g. user signup and login, admin controls, billing, reporting).
(Domain) events that happen in those processes (e.g. user account verified, widget created, invoice paid)
Decision points in processes and the input Data into those decisions.
I've used it a few times in large (30 people) and small (a couple of folks) groups to understand large and small systems, with outcomes that last long past the initial workshop:
To help build a shared vocabulary across group members
Identify projects to address problem areas
To build up a list of end-to-end scenarios that help define epics and test/demo scenarios to show progress in large projects.
What's so special about Event storming over <insert mapping technique>?
There are plenty of other process mapping techniques like user journey mapping, business process mapping (do you remember those BPMN symbols?), etc. The end results are effectively the same - a shared understanding of the domain that helps with team and project execution. What I like about Event storming is:
It is simple enough for everyone to understand and engage: I remember trying to run BPM workshops in the past and needing to spend lots of time explaining all the various symbols to the group. This was a distraction for participants. Event storming has a few concepts, but they can be explained quickly and introduced throughout the workshop.
You start sorting information early: During the workshop, you immediately start classifying information that is gathered; is this an event that happens, a decision, a question, or data that is passed around? I feel this is just the right amount of order without interrupting the flow of discussions.
Everyone participates - unlike some more formal mapping techniques, Event storming encourages everyone to write things down on sticky notes and put them up rather than relying on a dedicated mapping expert. This increases engagement during the expensive workshop, which helps get more value and enjoyment out of the process.
On the other extreme, I've heard objections that any process is too much for a workshop. Some argue that having a lightweight technique like Event storming is more effective than creating your own mapping process either in preparation for a workshop or, worse, during the workshop itself. I disagree with these objections, as I believe that a structured approach like Event storming can enhance the workshop experience and outcomes.
Tips for getting started
While incomplete, the Event storming book provides enough information to start. Based on my experiences, here's my summary of running an Event storming session in three phases:
The basic concepts
Event storming involves documenting (domain) events that happen in a process. These are represented as verbs (in past tense) written on sticky notes along a timeline. As you capture events, other information should come out:
Actions that trigger events are (present tense verb) "Commands" done by "Actors" (e.g., a new user signs up for an account). These Commands include decisions that Actors make.
Input Data for Commands, e.g. email address.
External systems and dependencies.
Policies represent things that happen due to events; e.g., when a user signs up, we have to check a watchlist.
Questions/concerns that arise during the discussion.
Each of the points should be captured on different coloured sticky notes.
And that's pretty much all you and the participants need to know to do Event storming.
Preparing for the workshop
Decide on the workshop's scope - When starting a new project or team, it's worth starting broad and capturing high-level process maps. Subsequent workshops can then deep-dive into specific sub-domains and processes.
Brainstorm some seed processes - to save some time during the workshop, it's helpful to pre-create a list of processes you want to map out. Work with a small group of domain experts. Don't expect this list to be complete or correct, as you'll collate more during the workshop.
Train some helpers - mapping exercises work best in reasonably sized groups (maybe up to 5 people at a time). A large workshop means you will need helpers to facilitate the breakout groups.
Book out a lot of time, several hours over multiple days - All workshops need dedicated time, ideally interleaved with time to decompress and absorb. Don't shortcut this!
Raid the supply cabinet - Unfortunately, you need a lot of sticky notes (one colour for each concept) and lots of pens (so everyone can write). Butcher's paper for the sticky notes (instead of whiteboards) is handy as it allows you to take the process maps with you after the workshop. Event storming could be run on an online whiteboarding app, but seeing a process map take up the entire room is satisfying.
Running the workshop
Event storming works best when all parties are engaged and participating. This means setting up the room as open as possible, with plenty of vertical space for the process maps. Participants should have easy access to put up sticky notes themselves.
To start the workshop:
Start broad before going deep. Collate the processes you want to cover before going in-depth into a specific one. Prioritize the processes so you can focus on the most complex (and controversial) ones. Your seed processes from preparation will help you shorten this collation and prioritization step.
Working through one process as a group. To help everyone get comfortable with mapping processes, do one that is reasonably complex (but not necessarily the most complex) together as a group. Throw an Event sticky note on the wall somewhere and start asking, ‘So what happens after…’, ‘who’, why, when, how? This should lead to Events, Commands, Data sticky notes flows. Encourage others to pick up a pen and write up a sticky note.
If you’re in a large group, you can break out. The challenge is ensuring you have domain experts for each process or subdomain. One technique to use is to rotate breakout group members. Each group has a set of processes to map and some time to Eventstorm. When time is up, all group members except one rotate to the next group. Try also to rotate the member who stays on the next rotation. If you can keep all the processes up on the walls, all workshop members can eventually see every process and provide their input.
At the end of the Event storming sessions, you can do walkthroughs as a large group, especially on the spiciest processes, i.e. the ones with gaps and lots of questions. This should hopefully seed additional thinking by the group (now or later).
Workshop Follow-up
Immediately after the workshop, the outputs should be captured durably and shared. These may include:
Documenting any specific terminology identified in a vocabulary that the team can use in future.
Capturing the processes into end-to-end scenario/test lists, epics, project plans, etc.
Capturing questions as tickets to follow up on, either as project work or backlog items.
The Event storming exercise may also highlight areas needing additional follow-up. These are processes, or parts of processes, with many questions.
Is this Domain Driven Design in disguise?
You may have noticed familiar terminology if you've encountered Domain Driven Design. The outputs of an Event storming session can be fed into DDD detailed design and implementation (and perhaps a benefit if you're in a DDD shop), but this is optional. Event storming (and other DDD analysis tools) are valuable in their own right.
Summary: Consider Event storming if you're jumping into something new
Whenever you're starting a new project or forming a new team (or your team is moving into a new area), we always ask, 'What's the fastest way to get up to speed?' As expensive as it is, collective time in some workshops remains effective. Event storming is a great way to run workshops; it has a good balance of structure with a low barrier to entry for all participants. If you get the opportunity, I recommend giving it a go.