Big Picture Eventstorming: A Guide on How to Explore with a Fast Learning Curve

BY Andrea Bersani

Ever read lots of documents to figure out how a process works? 

Ever spoken to other departments to better understand the overall process?

Ever drawn a diagram with all the interactions with your software?

If you’ve ever tried the methods above to cover the subset of the system to explore, chances are you might have been partially or totally unsuccessful.  

With Big Picture Eventstorming you will see the “big picture” in a single comprehensive diagram and you will reach this goal by sharing knowledge and problems, as well as clarifying doubts, so that anyone involved in this experiment will learn something.

What is Big Picture Eventstorming?

Big Picture Eventstorming is a DDD technique invented by Alberto Brandolini to explore the state of the art of your software with the collaboration of business, tech and UX professionals.

He starts with the assumption that when it comes to organizations where people are working together towards a common goal we are in some form of Complex Adaptive System, which is a network of interdependent agents influencing each other.

Its main characteristic is a complex adaptive system that won’t behave as expected!

This technique has the ability of explaining complex situations with a simple narrative.  It reinforces the collaboration between the “experts” and the others, throwing down the silo effect.

How does it work?

Gather all the key people, build together a model of the current understanding of the system.

Add details to your model incrementally with a facilitator in a time box diagram with certain phases.

Does it work remotely?

The first version of Brandolini’s unfinished book said that it didn’t work remotely.

Then the Covid19 pandemic came, and of course Alberto himself had to change his idea and let it work remotely but with some limitations. 

How can I start?

You can start with a simple example, for example with a story that everyone knows (like Little Red Riding Hood or the three Little Pigs) to introduce some key concepts:

  • Events (orange sticky note): This is a domain event, relevant for experts exposed with past tense verbs such as “Challenge Accepted”. An event is a fact, a thing that happened, something precise and relevant. It should be the result of an action or a user interaction, it should be triggered by external systems, it should be triggered by time or it should be the result of a cascading reaction or simply a consequence of another event.

  • Timeline: your board is chronological time space with time moving forward from left to right (put an arrow on the board to make this concept visible).

Everyone should feel free to add a sticky note to complete the story.

Only relevant facts must be added, and anything that isn’t relevant to the narrative should be left out (e.g. the “what big eyes you have” dialogue).

The point is not to tell a story but to better  identify the main events that make up the process.

Once the main principle is understood, we can move on to the different phases. 

The phases

The final result will come out once we get through the following the main phases.


  1. Chaotic Exploration: place sticky notes with events that make up your business process in the timeline. Everyone should feel free to add sticky notes. 

  2. Enforce the timeline: put events in the right chronological order, set pivotal events or swimlanes when processes take different paths. Extract key chapters.

  3. People and Systems: add persons which play a role in our model and add external systems as something outside our control (“whatever we can put the blame on”).

  4. Explicit Walk-Through: storytelling of all the events starting from the first. After the first round, do a second in the reverse order, starting from the last and coming back.

  5. Problems and Opportunities: everyone is now free to put a red sticky note on hotspots or a green sticky note to raise opportunities.

Phase 1: Chaotic Exploration

In this phase we should add all the relevant events that come to our mind. Everyone should feel free to add sticky notes to enrich our process and no one should remove them (except the facilitators). 

If you find yourself with duplicated events with different terminology, do not block this useful momentum as different terminology raises important ubiquitous language problems that we should solve in the next phases.

This phase could last 15 minutes to hours. It depends on the complexity of the process you are trying to explore. Like with any other phase, the important thing is that it should be time boxed. 

Phase 2: Enforce the timeline

The facilitator takes the reins of the meeting and the group starts to put some order in the timeline. The facilitator unveils the process, removing duplicates but keeping the events exposed with very different terminology. The facilitator is there to facilitate the process, all the decisions must be made by the group. 

When problems or questions arise throughout this phase, it is important to write them down on the red “hotspot” sticky note and leave the “hotspot” near the problematic events.

Then, the groups should work to organize  the flows using one or more of the following elements:

  • Pivotal Events: the most relevant events “pivot” with a vertical line to better separate the different “phases” of our process.

  • Swimlanes: some part of the process will be split into two parallel sub-processes, using a horizontal line to reinforce this concept.

  • Temporal milestone: it is possible to have events triggered by time, so put this temporal milestone (+1 month, +1 year) on the flow with a blue sticky note.

  • Chapter sorting: if the process is too long you can decide to extract the key chapters, order them separately and then rebuild the timeline.

Phase 3: People and Systems

In this phase, two new elements should be added: 

  • People: yellow sticky notes for each person with a specific role in the model.

  • External system: pink sticky notes for every external factor (remember, Alberto wrote “whatever we can put the blame on”).

The group will enrich the diagram with “people and external systems” to have a better understanding of the actors playing a role in our processes.

Phase 4: Explicit Walk-Through

In this phase the facilitator will take a domain expert to do an extended narrative of the process starting from the first event until the last.

With the explicit walk-through phase, you might realize that you had missed some important events before, and this will allow you to reorganize accordingly. 

If there’s enough time the facilitator will take another domain expert to do a “reverse narrative” starting from the last event to the first.

This will help clarify possible doubts and make sure that everyone is on the same page.

Phase 5: Problems and Opportunities

In this phase the facilitator will invite all participants to raise:

  • problems: a red sticky note with the description of the problem.

  • opportunities: a green sticky note with possible improvements or new opportunities in terms of technology or business.

After the first part, people can vote for the most crucial problem or greatest opportunity by signaling it with an arrow on a sticky note. This will lead to a list of priorities and possible future developments.

The result

After the first 4 phases the results look  like this:

What are the main problems for the online version?

  1. Number of people involved

    The “live” version is better for engagement and can include as many participants as we want, while the online version thrives on smaller groups (no more than 8 people), with no possibilities to carry on multiple conversations at the same time. The limited number of people in an online version makes it even more important to select and invite essential participants only. 

  2. Chaotic exploration could become unmanageable

    The chaotic exploration due to the missing natural subgroups and conversations that take place in person, could make  the remote experience more difficult. In a real room, the facilitator can check on the subgroups, correct them or recall the rules if necessary.  When the experience is conducted digitally, the facilitator could make up for the lack of personal interaction by presenting a board with the main pivotal elements, which would help everyone have some reference point for the chaotic exploration.

  3. Attention threshold

    While splitting up into subgroups tends to happen naturally in live sessions, a remote experience forces people to face a monitor, which doesn’t help retain attention. If a live session lasts an entire day, an online version should be split into several sessions, each one lasting no more than two hours (90 mins is what we would recommend).  

What are the benefits of this experiment?

  1. Determining your internal process and breaking down the silo effect

    Gathering  people who usually work in different departments could help the company have a better view of the overall process and break down the silo effect. This will help departments feel less isolated and more involved in the overall strategy to achieve organizational goals.

  2. Determining the strengths and weaknesses of your process

    Seeing the entire process should make it easier to identify strengths and weaknesses. The system can help everyone identify the problems of their department and help determine issues in the overall flow. The same consideration is also valid for the strengths that could help shed light on the things that work and don’t need improvement. 

  3. Speeding up the learning curve for newcomers

    A newcomer will get a descriptive diagram for the overall process. This will save months of training and give a clear starting point.

  4. A checkpoint for your startup

    In a startup, this kind of experiment must be repeated every six months, to get a good snapshot of your company’s organizational status and process evolution. It can serve as a checkpoint to find out how old problems have been solved and whether old strengths are still valid or not.

  5. A starting point for more deeper analysis

    You can select a subset of the overall process worth troubleshooting and explore it in greater depth. You can use this as a starting point for a ContextMap session to better understand the interactions between our software domains. You can use this as a starting point to design a new part of your software.

Is it worth it?

At BOOM, the engineering team used this system to explore obscure processes of the BOOM Factory’s production department and the result was astonishing.

In two sessions (less than three hours total), we discovered the part of the reverse engineering process that  a single person would take months to go through. 

We also used Big Picture Eventstorming to explain our main platform processes to newcomers.

In less than two hours, they managed to grasp the entire process, which would have been impossible without this system. 

Transformation visuelle en un clin d'œil