5 Views to Capture the Outputs of an Event Storming workshop

Recording the full Event Storming board is a waste of time. Here are examples of quick, focused, and digestible views that capture the board’s knowledge.

This is the second half of a mini-series about how to capture the outputs of an Event Storming workshop. If you did not yet, I recommend you to read the first half first.

The previous post suggested capturing single focus views of an Event Storming learnings. Here are some examples of such views.

💡 Do pattern matching on Event Storming board to ‘grep’ out focused views to take out of a session.

Capture Next Actions

During the workshop, we use pink post-its to capture subjects we cannot solve on the spot. These might be questions, quick fixes or problems.

Before closing the session, it’s a good idea to go through all these pink post-its and identify the next steps. These might be homework to do before the next session, tasks to add to the team’s backlog or refactorings to do.

Capture Domain Definitions

Open discussions between technical and business experts will clarify a lot of terms. This is the essence of Domain Driven Design. The practice is to write these down on definition post-its: usually large and yellow.

It’s a good idea to capture these definitions somewhere. One way is to stick them on the team’s workspace walls. Another is to add them in the code with Living Documentation. How to do it is up to the team!

Capture the Context Map

💡 Event Storming is a very effective way to build a DDD context map.

I’ve mentioned it before. During big picture event storming, we can identify the DDD bounded contexts. The context map is already on the Event Storming design board. It’s only lost within all the other post-its!

It’s very fast to sketch a context map on a piece of paper or a flip chart. It will also be a lot clearer to any later reader.

Capture user stories

The picture that explains everything by Alberto Brandolini from his Introducing Event Storming book

During design-level event storming, we will start to identify Aggregates and business rules. They always appear inside this post-it pattern:

We have discussed the context of the business rule during the session and add a few comments. This is a good candidate for a user story. “When user X does Y, he wants to see Z, in order to …”. As I wrote about before, it’s also the perfect situation to do a bit of Example Mapping.

Capture Input & Output Messages

At some point, most systems need to interact with external systems to be of any use. At the end of the Event Storming session, External Systems should be visible as blue post-its.

Again the Picture that Explains Everything shows us that we can spot interactions in 3 ways:

• Input messages:

• Output messages triggered by an actor:

• Output messages triggered by an event:

We can take some time to go through the board and spot these patterns. Every match is an input or output message for the system. We get even more benefits if we are zooming on a single bounded context in a Design-Level Event Storming. In this case, we should have modeled other contexts as external systems. We can also use any Read Model information to detail the content of messages.

We can then record this ‘API’ view of the board on a flip-chart. This can be very useful, especially if we are building a service oriented system.

Keep Maintenance in mind

Whatever the output, we should use cheap ways to record information. Photos, information walls or sketches fit the bill. We could also decide to invest in always up-to-date living documentation.

More expensive solutions will almost always be a bad use of the team’s time. Things will change, it’s a cheaper to build the system and keep the knowledge live in everyone’s heads. Finding out what not to do is key in maintaining a sustainable pace.

You have the answer!

The exploratory and intangible nature of Event Storming makes people uneasy. As a result, you might have faced puzzled faces when you first suggested to run an Event Storming.

Maybe you are only planning to run your first Event Storming. Whatever your situation, you now have concrete answers to convince action oriented people.

Give it a try! If you have other questions, check my full Event Storming walkthrough.

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!