How to Capture the Outputs of an Event Storming Workshop?
Event Storming builds ‘shared understanding’. This is often not enough to bring key action-oriented people in! Here are concrete techniques to convince them.
When I started to run Event Storming at work, I would often receive puzzled looks. Action oriented people would ask: “What are the outputs of this expensive Event Storming workshop you want us to do?”. Here was my typical answer. “We’ll get shared understanding, identify quick fixes and hotspots. We might also be able to draft a functional architecture…”
Putting shared understanding as the main output did not convince them.
Since then, thanks to a few early adopters, we’ve been able to make the value of Event Storming more obvious. It is becoming a de-facto standard for early architecture of new features. To achieve this, we had to better explicit what the outputs of Event Storming are.
But first, let’s go through the usual answer.
Shared Understanding
Wherever you’ll look on the web, you’ll get the same answer.
💡 The main output of an Event Storming workshop is the shared understanding.
This is true. This is the main output of Event Storming.
Let’s see what this answer means. Event Storming can kick-start the team in a state of high bandwidth communication. The team will remain hyper-productive as long as it stays in this state.
This ‘jelled’ state opens up many improvements:
- it reduces the need for processes as people know what’s the good thing to do
- it simplifies code as people understand the problem better
Finally it also leads to a sustainable rhythm of steady refactoring:
- Event Storm
- Start building something
- Learn and get feedback
- Event Storm (or other) again, with the benefit of this new knowledge
- Incrementally refactor and add new features
- Learn and get more feedback
- …
This is the main output of Event Storming. Let’s now see how to capture others in a concrete manner.
Capturing decisions
Many discussions happen during an Event Storming sessions. Some of these discussions will lead to decisions. It’s a good idea to keep track of these decisions somewhere to avoid forgetting them.
I tried to use special post-its to keep track of decisions, to no avail. The Event Storming post-it bestiary is already complicated enough. In the end, Alberto gave us the right answer. The simplest thing to do is to keep a flip-chart close to the design board and record decisions there.
Depends on the decisions, and on the context. Usually putting decisions on a flip chart and sharing pictures might do the trick.
— Alberto Brandolini (@ziobrando) 15 mars 2019
A photo of this decision board can serve as a minimal log of what happened during a session.
Capture outputs through curation and views
While you are in an Event Storming session, the design board remains crystal clear. Unfortunately, if you get back to it after a few weeks, you’ll have a hard time making any sense out of it. That’s why keeping the full board, detailed photos of it, or a digital re-transcription of does not work very well.
There is something we can do though. We can capture filtered and single focus views, making the information digestible. A context map for example, is easy to draw after an Event Storming session. Next week’s post will go into more details about different views.
💡 Capturing filtered and single focus views of the Event Storming board, makes the information more digestible and persistent.
Share all this with a Safari
If we need to share the outcome of an Event Storming session, we’ll be better equipped with these views. We can invite people to a Safari following these steps:
- With the help of one or more attendees, go through the full narrative
- Then go over and explain all the views
This is good way to share as much information as possible in the shortest time possible!
To be continued
This was the first half in a mini-series about capturing the outputs of an Event Storming workshop. Next week’s post will dive in more details in the different kind of ‘views’ we can capture out of Event Storming.
Leave a comment