Facilitating Event Storming
Domain-Driven Design modelling for Agile teams, Brandolini-style.
Published on 28 August 2013 by @mathiasverraes
Event Storming is a technique where you get the developers and the business stakeholders in a room, and visualize the
business processes. You do this using stickies with domain events and causality (such as commands), and end with drawing
boundaries for aggregates, bounded contexts and subdomains. It’s developed by Alberto Brandolini and is deeply rooted in
Domain Driven Design, and CQRS/ES.
I facilitated an Event Storming session with the team of Qandidate.com in Rotterdam. I’ve read an early draft of Alberto’s
paper on Event Storming, that inspired most of what I did. It was my first time doing this as a facilitator, so I’d thought
I’d share my notes. It’s just the raw material – I was going to process them into something more
readable first, but Jef Claes convinced me to just post them as is. So forgive me if they are vague; I promise I will blog about
Event Storming more later.
Despite my rookie mistakes (too much intervention, then too little) the whole thing went very well. The team was very
excited, they want to do it again with their founders. We also did a bit of context mapping for the legacy systems of
their parent company, but time ran out.
I think there are three main reasons for Model Storming:
- Discovering complexity early on, finding missing concepts, understanding the business process;
- Modelling or solving a specific problem in detail;
- Learning how to model and think about modelling.
- Hang the first sticky yourself (a tip from Alberto, works really well)
- Know when to step back. Don’t do the modelling, guide the modelling
- Ask questions:
- Is there something missing here? Why is there a gap?
- How does this make money?
- How does the business evaluate that this is working? What are the targets, how will we know we’ve reached them?
- For whom is this event of importance (end user, business, tenant,…) ?
- I can’t see this particular role, or type of user, in this model. Should they be on here somewhere?
- Change the direction, e.g. start at the end of the flow, move back in time, then later start at the beginning and move forward.
- Interrupt long discussions. Visualise both opinions, and, very important: ask both parties if they feel their opinion is accurately represented.
- Timebox, using pomodoro’s (25 minutes). After each pomodoro, ask what is going well and what isn’t. It’s a good opportunity to move to the next phase (e.g. from adding events to adding causality, to drawing aggregate boundaries). You may want to move on even if you don’t feel the model is complete.
- Constantly move stickies to create room for hotspots.
- Hang red stickies with exclamation marks, question marks, or other notes, anywhere you feel there’s an issue.
- At the end, make a photo. Then tell them to throw the model away, and to do it over the next day. If possible in the presence of other stakeholders.
- I personally prefer sentence-style event names (“A product was added to a basket” vs “Product added to basket”). I believe this makes the business people feel more comfortable.
Follow @mathiasverraes on Twitter.