Discover your business process through EventStorming

Two years ago I heard about EventStorming for the first time. I read about the technique, and I was not immediately convinced by it. One Master Class and several EventStorming sessions later, I’m writing this blog post because I think you should give it a try.

Let’s start at the beginning.

EventStorming is a flexible workshop format for collaborative exploration of complex business domains — Alberto Brandolini (Eventstorming.com)

EventStorming can be used for different purposes. There are two formats in particular in which we see the potential at PENCIL42:

1. the common understanding of a business flow, aka the big picture format
2. the design of an event-driven architecture, aka the design-level format

In this article, I want to dive deeper into the big picture format.

What you need:

• the right business people i.e., people who are experts in their domain, people from different domains/departments, people who care!
• a lot of post-its
• a big roll of paper on the wall, to place the post-its on
• a room with a lot of wall space
• you i.e., the facilitator
• depending on the size of the domain, half a day to a day of everyone’s time

The EventStorming technique puts your key business people to work. All they need to do this is write down every event they can think of on a post-it and put the post-its in sequential order. Just to be clear, events are things expressed in the past tense. The business flow of writing a blog post could, for example, contain the following events:

• new blog post draft started
• review of blog post requested
• blog post scheduled for publication
• blog post published
• blog post shared on Twitter

Automatically discussions will start happening, and once you take a step back, you will realise that the real business process emerged.

By the end of the workshop:

• you will know what the business flow looks like right now
• business people will understand their own business process from start to finish, cutting through different departments and responsibilities

Once the flow is clear, the participants can identify the risks and opportunities. This allows them to decide where to spend efforts.

Depending on the organisation, modelling a business process, using classical techniques (e.g. BPMN or UML Activity Diagram), can be quite painful:

• You need to talk to many different business people to understand the process from start to finish
• each person you talk to only knows part of the story
• the workshops to gather this information are not the most dynamic
• and somehow when you finish documenting the business process, you have this eerie feeling that you couldn’t get it quite right

The Big Picture EventStorming technique tackles many of these points:

• you put all relevant people together in one room
• you let them describe the flow
• discussions that need to happen will naturally occur
• not only will you understand the flow, but everyone involved in the workshop will do so too
• pain points and opportunities in the flow will be very visible for everyone

This technique might not be for people who want precise modelling techniques. In any flow, you will have alternate, parallel, optional flows, and who knows what else. If you use a classical technique (e.g. BPMN or UML Activity Diagram), everyone who reads your diagram will interpret these scenarios in the same way, as they provide a clear modelling language.

This is not the case for EventStorming.

• Are there things happening in parallel? Maybe you can put them in a vertical list
• Is there an alternate flow? You could just add some tape above that part of the flow and give it a name
• Do you want to indicate that something is triggered by time? Perhaps add a post-it with a clock
• Some actions are repeated x times? How about a post-it with a loop?

There is no formal notation for any of this, you just make it up as you go, in whatever way makes the most sense to you at that moment. This is the part I’m less comfortable with. I like precision, and I have a hard time being precise with the technique.

One of the main prerequisites of a great EventStorming session is having the key stakeholders in the room, but your main stakeholder is missing when you use this technique: the customer. It is dangerous to think you’re considering all aspects when you might lose sight of the customer’s perspective.

So now you have a business flow. How does this fit in with other techniques such as user story mapping and customer journeys?

The Big Picture EventStorming is applied at the very beginning of a project or even before. It allows not only me as an analyst, but all the involved business stakeholders to have a common understanding of the business flow. As this is an opportunity to spot where to improve the flow, it can be a great way to identify which project you should do first.

Customer Journeys have an enormous focus on the way the customer approaches your product or service and places it in a wider context. In the Big Picture Event torming the customer is taken into account, but there are no customers present in the workshop to share their insights. I think this is one of the pitfalls of the Big Picture EventStorming, it can take you back to inside-out thinking as it lacks focus on your customer.

User Story Mapping is a technique that I use for every project. It helps me to have an overview of the required functionality of a solution. It allows me to make sure that there are no gaps in the solution, and it facilitates the planning of releases.

So for me, all three techniques have their own purpose and can co-exist.

There are several ways in which you can document an EventStorming session:

• if you used a big roll of paper, you can hang this up close to the team
• you can also document this in confluence using plugins like draw.io, gliffy or my personal favourite miro

The most important thing to realize is that the business process is constantly evolving, regardless of the technique you’re using. By the time you leave the workshop, the flow might have already changed.

So whatever you choose to document, it’s a snapshot of a common understanding at that moment in time.

The goal is not the documentation. The goal is to gain a common understanding of a business flow, and the risks and opportunities it is facing.

Is it the perfect technique that will solve all of your problems? No. But I do think that it is a technique with great value, that is worth incorporating in your analysis toolbox.

For the exact details on how to facilitate the workshop, I recommend reading Alberto’s book or feel free and contact us.