What to say at the beginning of a Big Picture Event Storming

Congratulations! 10 or more people are now in the room looking at you, wondering how to get started… Don't panic: here is your briefing script.

Your Big Picture Event Storming briefing should introduce:

1. The general goal
2. The scope and use cases
3. What a domain event is
4. What a domain definition is
5. How to record questions and problems
6. And a few simple rules to ensure the success of the workshop

Here is how we usually start our Big Picture Event Storming workshops

Make sure you read the previous posts covering the workshop preparation work.

Introduction: why and who

Thank you for being here. I'm <your name>, and I will be your facilitator during this Event-Storming workshop. Before you start, let me share a few guidelines.

The primary outcome of this Event-Storming workshop is the shared knowledge between domain experts and developers. That is why [Name], [Name] and [Name] are here, as domain experts and [Name], [Name] and [Name,] as developers.

You'll build on this shared knowledge to draft a target architecture, but it can also help you make many other complex decisions.

Now that you know who is here and what this workshop’s goal is, let’s see how it will go.

Scope and use cases

Today, you'll cover <your scope>. To make things more concrete, you'll explore the following use-cases <list your use cases>.

Domain Events

You will start by identifying domain events that happen during these use-cases, such as <your 1st event>. A Domain Event is simply something that happens in your system.

As you can see in this example, you will use orange post-its to write events using past tense. This is a grammatical trick to create meaningful events. Events are not actions of someone (not "The trader books the deal"). Even though some events will result from actions, we are not interested in actions yet.

Here are a few more points to help you understand what domain events are:

• They are not technical and should not be specific to your system's implementation
• You could read about them in domain books
• Domain experts understand them

When we use the word domain, it means the specific topic for which the system is developed. In your case, the domain is <your domain> (ex: trading book)

When identifying the events, you will be able to organize them in chronological order on this enormous piece of paper that you see on the wall.

Domain Definitions (aka Ubiquitous Language)

Whenever you come across or agree on a domain word that may be confusing, feel free to define it on a large yellow post-it

Writing down the domain definitions is like building your own dictionary of what the words mean in your context. It is also called the domain’s ubiquitous language. This is very useful to prevent misunderstandings between all of you by making things as explicit as possible. This, in turn, improves how you work in many different aspects (ex: when choosing what to build or even refactor). Remember: the primary outcome of this Event-Storming workshop is shared knowledge.

Problems

Likewise, you will use purple post-its to park "problems." Whenever you encounter:

• a question you cannot answer
• something that does not seem right
• or any problem you should look into

Record it on a purple post-it.

Last things to know before starting

Before we look at the detailed agenda, here are 5 crucial things that you should know:

1. You must stick to domain language to keep this collaboration alive. 💡 I've seen Event Storming sessions drifting into technical discussions; this leads nowhere.

2. Event Storming is a visualization technique. Make sure you capture the topic that you are discussing on a post-it. Remember that you should never be talking about something not yet displayed on the wall.

3. Remember that Event Storming is a way to shrink months of Big Design Up Front into a few days! It's going to be intense, but you'll accomplish a lot in a short time.

4. Event Storming might feel chaotic. It might be rocky and go in unexpected ways at times, but we will adjust. 💡 At the end of the day, though, the success mainly depends on how much you all want it!

5. Finally, to keep the workshop pace sustainable, we'll take a 5-minutes break every 50 minutes.

And then what?

Once this introduction speech is over, we quickly present the different steps of the workshop. That's for the next post, so stay tuned!

---

This blog post is part of the 1h Event Storming book that we are currently writing.

An earlier version of this post was originally published on Philippe’s blog