Event Storming & Domain Storytelling

HOW TO ACHIEVE HIGH-QUALITY RESULTS IN SOFTWARE PROJECTS FASTER?

When automating operations, the goal is always to enable the users to work more efficiently. Their work must go faster thanks to the new software to enable them to be more productive or assist customers even better, for example.

We now know that IT is not a goal in itself but must always support and facilitate the business. However, things can go wrong during development projects because the business and IT fail to speak the same language from the start.

As a result, certain issues for which the new application must offer a solution are only discovered later during the project. The developers will then need to adapt the code, making the project last longer than necessary.

Event storming and domain storytelling offer an answer to this problem. You will immediately, quickly, and thoroughly define what is expected of the new software. We will use this whitepaper to explain how to do this.

KEY TERMS

Domain-Driven Design

A ‘domain’ is the company activity for which an application is being developed. This can be ‘sales’, for example. A domain is often divided into sub-domains. Domain-Driven Design uses real situations that are important in a domain as the starting point of the development.

A shared language

In Domain-Driven Design, it is very important to develop a shared language. This applies to everyone involved in the project: the developer, the business manager, the analyst, the tester, and the marketing employees, for example. They must all use the same terms to ensure everyone knows what you are talking about. The developer will need to use a term in the software code used to retrieve an order that is recognisable to the sales department. This can avoid numerous misunderstandings, enables the developer to start programming much faster, and makes the code much clearer afterwards.

One man, one marker

In the classical meeting, there is one person standing in front of the group speaking and taking notes on a flip chart or whiteboard. However, you can also organise an interactive meeting, where you first discuss the topic in small groups. Each group will come up with an opinion or solution, which is recorded by the person in front. The difficulty of this approach is that some persons are more dominant than others within a group, due to which their voice is given more attention. Other, just as useful, opinions, will be lost in this manner. The outcome of such a meeting will always be somewhat disappointing as a result because not all opinions have been discussed and you have not reached the expected results.

Meetings may also suffer from a depleted marker situation: the person at front wants to write something down but the marker fails him. The flow of the meeting is disrupted completely to find a new marker. The focus among the participants disappears at this moment. If there are ten participants and it takes ten minutes to find a new marker, ten times ten minutes are lost – a lot of valuable time for a simple marker. It may seem obvious, but this is a recognisable situation you should avoid at all costs.

EVENT STORMING

In event storming, you organise a meeting where everyone will think about the issue of your domain and visualise this. This makes the later coding much faster: you have a much clearer idea of where you want to go.

What is event storming?

Event storming is a way of modelling processes using a timeline with ‘events’ – events or actions that can be automated, such as ‘an order has been placed’ or ‘the order has been confirmed’. There is no best practice for event storming and there are no fixed rules that must be observed. However, there are guidelines that you will need to adapt to your needs, your own team, and your own processes.

You should mainly expect plenty of sticky notes. It is not a regular meeting, but a workshop. A first event storming session is often somewhat chaotic, but, in the course of time, you will become increasingly better at establishing order and working towards a goal.

Types of event storming

Since there are no fixed rules for event storming, there are many different types. You can place them in two categories: ‘big picture’ and ‘design level’.

Big Picture is large-scale event storming, in a large space with many people – even up to 20 participants. You will map out the complete business during this approach, which is precisely why you need many people. You will also hear many opinions. The goal is to make the largest difficulties and risks in your entire flow clear and to possibly propose new solutions and ideas.

Design level meetings are completely different. These take place at a much smaller scale with a significantly smaller number of people, because you will focus on one key feature. The participants can consist exclusively of members of the development team and the domain experts, for example. The goal is to fully define one aspect of the domain before writing a single line of code. Afterwards, you will develop a prototype or proof of concept (POC) as soon as possible that can be checked based on what you have captured.

Big picture event storming is clearly much more complex and does not immediately lead to tangible results. The main benefit of this form of event storming is that you identify the issues and, thus, the priorities the development team must address first.

EVENT STORMING IN SEVEN STEPS

Step 1: Preparations

The participants

You will invite three types of people:

• A facilitator or moderator: to keep things on track. Does not need to know everything.
• People with questions
• People with answers

Of course, ‘people with questions’ and ‘people with answers’ are not distinct categories. Some people will know virtually everything about a certain subject, for example, and these experts should definitely be invited. At the same time, you will also involve people in the session who are new and will be working with the software. They can sometimes provide answers that an expert would never have come up with.

Always make sure that the participants have different backgrounds, stem from different departments, or have different areas of expertise or insights. This will benefit your later result. You must always combine technical profiles with people from the business.

The space

A large work surface is very important for your event storming meeting, preferably a hanging roll of white paper. You will need at least 8 metres. Alternatively, you can simply work on the wall using static sticky notes.

Create a legible legend next to your work surface in advance. This is often a flip chart to the side. The legend will list the different colours of sticky notes you will use with an explanation of their purpose. For example, you can use orange for ‘events’ and blue for ‘commands’.

Sticky notes and markers

You need a large number of sticky notes in a variety of colours. Preferably, a couple of hundred.

Give each participant at least one marker and arrange three to five extra markers as a backup to avoid having to pick up additional markers during the session – the depleted marker situation.

Furniture

The organiser must be present first. Move the tables and chairs to the side, possibly stacking the chairs. You want to make sure that people do not immediately sit down once they arrive. The participants may feel somewhat uncomfortable because they will need to stand, but this actually energises them. You can keep chairs at hand for longer sessions.

Food and drinks

Arrange healthy food and drinks during longer sessions, such as water and fruit. People have an easier time thinking when they are eating and can hold onto something.

Step 2: Start

At the start of the workshop, the moderator will give a brief introduction in which he or she explains the goal of the session. You will tell that you will place ‘events’ on the work surface, that you will place them onto a timeline, and that you will attempt to map out the business or a specific feature in this manner. You will then look for ideas and potential solutions and place these on the work surface as well.

Your introduction and your explanation of the issue you want to resolve will need to be very brief, not more than a few minutes.

Afterwards, you will actually get to work. You will hand everyone sticky notes and a marker and agree on a few rules, for example, that an orange sticky note is used for an event. You will ask everyone to write down the events that they believe will take place. Important guidelines are that the verbs must be in the past tense and that everyone must use relevant terms (a shared language).

The participants should not think about the issue for too long and should start writing things down quickly. Many people feel somewhat uncomfortable doing this and will not know how to start. Once someone has placed the first sticky note, the ice will have been broken. If this takes too long, the moderator can guide the process by saying something or by possibly placing the first event down himself. Afterwards, it is up to the participants.

Step 3: The timeline grows

If people start to discuss things during this phase, you should interrupt this and ask them to work alone without speaking. Everyone will place the events randomly onto the surface. There are no wrong events. Any discussions will be a waste, as they will not be posted.

You will evolve towards a timeline with events. Things will quiet down at a certain moment and the participants will gradually stop writing. They will often take a step back to take a look at the bigger picture. They will also study the sticky notes placed by others.

The typical image is one of a number of clusters of sticky notes that have not been organised into an overall picture.

Step 4: Organising the timeline

During this phase, you will remove the duplicate events and organise the remaining sticky notes. This always leads to – often heated – discussions about numerous details, like a name. These discussions are definitely useful because they point out issues or inconsistencies that pop up. By making these visible on the timeline, they are now being discussed, instead of forgotten or hidden away.

Try to introduce a level of logic to your rough timeline by sorting the events from the left to right. You can use one of these strategies to sort more efficiently:

• Pivotal elements: Label the most important events in the flow using coloured tape. These will usually be the events that the largest number of people in the room are interested in. For example: a placed order is interesting to the marketing, accounting, and shipping departments. You will have an easier time sorting the remaining events once this has been completed.
• Swim lanes: Create horizontal subdivisions per department or ‘actor’ (the person who performs the action in the event). The benefit of this approach is that your timeline becomes very legible thanks to the lines. The downside is that you need a lot of space, especially vertically. For this reason, the division into ‘swim lanes’ is mainly useful to present one process/key feature or once you have already made a provisional structure that you subsequently divide into swim lanes.
• Temporal milestones: These are especially useful if you have many simultaneous processes. You will hear discussions between the participants about the precise order of the events. You can, for example, designate important events that should have been completed a month or a year ago using blue sticky notes at the top of your work surface. This approach can be adapted to your business or domain issue. This allows you to create ‘time zones’ in which you sort your events without an overly strict chronology, leading to much fewer discussions about the precise order.
• Chapters sorting: This approach is mainly used if you do not have enough room in your space or on your work surface because you already have many events. You will not sort everything at once, but will first select the most important ‘chapters’. You sort these on a separate surface – a table or a floor, for example. You will then sort the rest in the same way.

Step 5: Identifying relationships and issues

Look for the cause of events

Once your timeline has been sorted, you will decide what happens before the event. For example: what is the cause of ‘an order has been placed’? There are various options:

1. A ‘command’: an action by a user, for example, somebody who clicks on the ‘place order’ button on the website. You will write the commands down on a blue sticky note.
2. It comes from an external system, for example, a payment through PayPal. You will write this down on a pink sticky note.
3. It is the result of the passing of time – something that happens automatically at set times. Draw an icon on your event with the time interval, such as 30 minutes.
4. A response to another event. Use a white sticky note placed between the two events (if/then).

Designating hotspots

By visualising certain flows, you also discover ‘hotspots’ where friction exists and which you will designate in the business flow. People in the room will notice when a certain flow fails to work properly. They will make remarks that they will write down on sticky notes and place near the hotspot. They will write down the issues and the potential solutions or ideas on sticky notes in different colours.

Step 6: Check everything

Walkthrough

This is not the end of the session. Ask somebody to study the flow by physically moving along the sheet and telling what he or she sees and what is happening. If they falter or must go back a step, you can identify where the flow has not yet been sorted properly. Interrupt the person at the front, and ask and check if everything is in the right place. Test the story that was told and sort everything correctly. The area to the left of the speaker will be correct, while the right section needs to be sorted better.

Reverse narrative

Once this has been done, move to the flow again, but this time from the back to front. Are all the steps placed before the last event actually all the steps that must be completed to achieve the result? This gives you a better idea of the bigger picture. Often, you can place additional events on the timeline.

By using the ‘reverse narrative’ technique, you encourage participants to think differently and can discover if there are still ‘magical gaps’ in the flow.

Step 7: Result

Ultimately, you achieve a very clear and coherent business story that all people in the room understand. The newcomers have an idea of how the business works and what the structure of the flow is, the experts often discover things they had not yet thought about or did not yet know. If you have mapped out your entire business during a Big Picture session, you can also see which domain you must address first to find a solution, and where things often go wrong in the existing situation. This is very difficult to determine in regular meetings.

DOMAIN STORYTELLING

Domain storytelling has some connection with event storming. You learn about your domain or language by telling a story and bylistening. While you listen, you capture everything in images to enable you to follow the story easily. You also immediately ask a lot of questions and ask for feedback from the person(s) you are talking with.

An example: you are a developer and want to create an online ticketing system. You talk with an employee, the manager, and the administrator of the existing ticketing system.

You first ask a number of questions, you learn about your domain, and you briefly discuss what the application should be able to do, based on the actual use. Draw/write down a diagram or flow chart for each ‘use case’.

Imagine the scenario for purchasing a ticket. The question will be: ‘What happens today? How can someone order a ticket?’ The answer: ‘The customers visit, call, or send an email.’ Based on this information, you select the method that demands the most time: when people physically visit the counter for a ticket. How does this happen today? Use the specific names known by everyone at your organisation when creating your description. If a cash register worker at a zoo is called a ‘ticket giraffe’, write this down and use the language of the business, for example.

By having people talk about the way in which the process is taking place today, you discover where there are issues without an excess of confusing information for the customer. You can also write down the potential solutions that must still be studied, such as placing a brochure at the counter or installing an additional screen that you can rotate to the customer to show information.

You will have succeeded once all people present accept the ‘domain story’ you have drawn. Afterwards, you take a look at your initial diagram. You can often already remove a number of lines in this diagram because not all scenarios will be connected to all systems. Approach each use case in this manner.

The goal is to learn as much as possible before starting to write your code. You will only start programming once you have a comprehensive idea of the way in which the application must actually perform.

CONCLUSION

By capturing as many things as possible visually in advance, you can significantly reduce the development time of a new application. You will have a much better idea of what the final result must look like and will need to make fewer changes afterwards. By intensively involving the business in the project from the start, everyone will be pursuing the same goal, making communication go a lot smoother.