What is EventStorming?
How would I describe the EventStorming technique? It’s a straightforward, intuitive, enjoyable way to discover the domain and business processes both in startup and in corporate environments. All you need is a lot of sticky notes, plotter paper and the right people. Easy.
EventStorming is divided into three stages. They differ from each other in the level of detail you are going to discover.
Let our captain Cattin take you on the trip in his spaceship. You are currently hovering above the earth. You are not sure where you are or what to expect in the immediate future.
Stage 1 — The Big Picture
Every spaceship needs a map. Not a detailed one but a general map of the area to get the decent picture of the place. Just like in a company. People need to know where they are and what to expect around the corner.
Your recipe for this stage
- Invite the right people
- Provide unlimited modelling space
- Model the whole flow with events on a timeline
The right people are those who know things in your company. Let’s call them “domain experts”. These are usually the managers, technical people, accountants, whoever may have the knowledge necessary to draw the “map”.
You need to prepare a room for the session. Everything should be different from a normal meeting that usually takes place while sitting around a table with people bored to death in front of their laptops. We do not want that.
Hang a paper roll on the wall. Remove all the chairs. You can leave one for somebody that may really need it. Invite the people into the room. Ask them politely to switch their phones and laptops off. And the party begins now…
Thank everyone for their time and tell them you would like to understand the business processes in the company. And in order to achieve that you need them to help you build the map to see the whole picture. Everyone is responsible for their fragment of the big picture, their piece of knowledge (domain). Ask the participants to stick orange stick notes with the business events written in the past tense. In whatever order.
Let me give you a few examples.
At first, people will be confused… The best thing that can happen is an icebreaker. It is someone who sticks the first sticky on the wall. You can have a secret helper that will do that for you. We need to appraise him/her publicly. The others will follow.
- Asking questions first
- Agreement upfront — we need to be spontaneous
- The committee — everyone must write on stickies — break circles
- Starting from the beginning of the roll
- Karaoke star — the one who tells everything, while everyone else is quiet
- The icebreaker
- Making a mess
- Starting from the center of the wall
- One person — one marker
- The infinite buffet — markers, stickers, wall
- Just do it — I’ve never asked to do it right
People will naturally want to ask questions first, but this is not what we want. We need them to act spontaneously. All the upfront agreements will stop them from doing so. Do not start from the beginning of the roll. The middle of it is where you want to begin. Also, be on the lookout for the karaoke star who may take over the workshop.
If all goes well, the domain experts will show us the mistakes — this is how we learn. We should be grateful for that.
Soon we’ll have clusters of orange stickies. There may be a few notes not in past tense. There will be some detailed stickies and some very simple. People are different! You are expecting chaos at this moment, right?
Please, don’t correct the participants too early. The most important thing is their engagement.
If there is something you will need to discuss at a later time, please slightly rotate the sticky. Like on the picture here: “registration” is a process name, not an event.
Yes, you feel like you have a whole lot of mess! And that’s the point of this stage. The big, spontaneous pile of stickies!
Everyone will be trying to tidy up the timeline. If something is wrong, it will trigger the expert’s explanation.
It’s time to sort our map. Here is a handful of strategies.
If you identify many duplicate events, pivotal events (key events) use the yellow tape to show them.
You can identify process flows here. If there are more than one you can sort them using the swim lanes. This sorting strategy may result in some detailed picture.
Temporal milestones can be time points. For example:
- -10 weeks
- -2 days
- +6 weeks
Present them using rotated blue stickies just above the roll.
You can add lines to sort chaos. You can remove sticky notes and sort them somewhere else to put them back on the board again.
Business and IT cannot agree? Why not help them by allowing them to use two different colors to show the events. You can merge the two lanes when they are finished.
Stick everything onto the board. You can add another roll if the wish list is mixed with reality.
Time for more colors
If there are disagreements, remember that ONLY the facilitator may add the pink stickies. We need the participants to think about events while not stopping on problems.
Some disagreements may be significant. Look at the participants. Are they interested in the topic? If so, don’t stop it with the pink note.
What happens when there is an abbreviation or some word you don’t understand? Simply ask for the clarification and add a big yellow sticky at the bottom of the paper roll.
People and Systems
It may appear many times. Actors can be different, for example, trainer, student, Web user, etc. Actors can be specific people themselves — how about Ann or Paul?
What happens if you have the same actor in many steps? Use some tape and put a title on it.
Use a big pink sticky to blame software, systems, bad luck, bad weather, government. Everything can become a source of trouble.
How to finish Big Picture session?
At the end of each round we ask two questions:
- What is still important?
- What is missing?
Please note. Developers almost never remember about money. Business will add events connected with money in/out.
Problem and Opportunity Step
Ask everyone to stick pink problems and bight green opportunities.
The Final Act
Give the participants small blue stickies and ask them to draw an arrow on each one. Two arrows per person. Ask them to point it at a pink problem or a light green opportunity that they think may be important.
Thanks to the arrows you will know where to start first. Neat, right?
Stage 2 — Process Modelling
During this stage, you will learn about process flows in the company.
This is the stage that will allow us to learn the company language.
Canonical language — this is the common language which is mandatory in the company.
Ubiquitous language — this is the common language but within a bounded context. People speak this common language inside silos. When we try to make the language universal outside the silos throughout the whole company — we fail.
When saying “silos,” we may refer to people who have detailed knowledge about their area of expertise. Silos inside the company share some insight about their processes. But nobody knows everything about the whole company.
Prepare the following sticky notes
Having prepared all the above, you are ready to model processes according to the pattern below.
When sticking the notes onto the roll keep to the following pattern. It will make it easier for you to arrange them in a sensible order.
What happens in the above picture? A user having read the required information is making an action that triggers a system which raises an event. This leads to either another read model presented or some policy triggered which results in further operations.
Let me explain what policies are.
A policy starts with “whenever”. Policies describe habits, individual choices, conventions, agreements, official rules, etc. These can be listeners or process managers.
Policies are brilliant lie detectors. Just start a sentence with “whenever” or “immediately.” If it sounds stupid, try to modify the view as below.
During this stage, it is vital that you go from the beginning to the end of the process as fast as possible. Rush to the most straightforward outcome possible. You will add more paths at a later time.
Remember to show the outcomes of the processes, too. Sometimes the end user may be happy, sometimes not. Sometimes the process will bring money to the company, and sometimes it won’t. Use yellow actor-stickies to show the outcomes with pink or green smaller notes like below. This is the perfect place to show the money flow.
The smaller notes are:
- Light yellow — the actor: me, customer
- Light green — value created
- Pink — value destroyed
After the first run of this stage, we will go deeper exploring more and more scenarios. Be aware of the rabbit hole, though.
Some scenarios are so infrequent that they are not worth exploring.
Outcomes and Formats
- Easy — no politics involved
- No arrow voting — no bottlenecks yet
- Investigate value
- Business model canvas & friends
- Exploration of the environment and people
- See who is going to block and what are the risks involved
By this time, you will have explored the scope you were pursuing which will give you the estimation for the project. As a bonus, your exploration area will identify risks and blockers.
Stage 3 — Software Design
During this stage, you will need the following stickies.
Converting Process Model into Software Design is easy. But this time the difference is that we will be identifying the aggregates. Let’s look at the following example. A user is making a purchase decision based on the website information. The Initiate Purchase command is issued on the Purchase aggregate that creates the Payment Initiated event — the PayPal Purchase Policy than initiates the further flow.
- Solve everything
- Discuss invisible things
- Doing things right the first time
You cannot solve everything. That’s not the point of this stage. We need to find out the most critical flows. Don’t discuss invisible things. If a problem is doubtful to happen or have any real influence ignore it.
Remember, it’s not possible to do everything right on your first try. You will make mistakes — that’s perfectly normal. This is why we are using stickies — to replace them quickly and with no worries about their cost. It’s better to throw away paper than the time of your programmers, designers, product owners, etc.
- Make everything visible
- Look for symmetries (start purchase -> end purchase)
- Speak out loud
- Sound stupid to make people correct you
- Postpone naming
- Rush to the goal — then add alternative paths
- Make some noise (trash) — continuous rewriting
- Raise the bar — this will come in handy to see which of two similar solutions works better
Use the sticky notes to make your ideas visible. Actively look for symmetries — seat available -> seat assigned, purchase started -> purchase finalized. Speak your thoughts out loud. Do not hesitate to sound silly as this will make people correct you and share the knowledge with you.
Don’t name your aggregates as soon as possible. Use some other naming convention. How about “alpha”, “beta”. This will enable you to think deeper and find more suitable names than the ones you came up instantly at the beginning. Also, thanks to this approach you are not limiting your aggregates to a socially acceptable set of methods.
Rush to the goal using the most positive path. Then add more scenarios.
Don’t hesitate to throw away the stickies. They are cheap. Your ideas can evolve and change freely.
Do you have two similar ideas? Then raise the bar and see how they can handle different scenarios. Choose the more flexible one.
Time to identify and list those aggregates that are lurking around your project.
This is it
If you and the colleagues around you feel very tired but satisfied and the paper roll is easy to read this means your mission is complete. Your development team can use it as their map and I can guarantee you that this will significantly speed things up while cutting the development cost down.
If you need the detailed and very thorough EventStorming explanation, go to the famous Introducing EvenStorming book by Alberto Brandolini who is the inventor of the technique. To see how this technique was applied in real life please check out Paweł Rekowski’s article.