A step by step guide to Event Storming – our experience
Usually, at Boldare we start each product with some kind of kick-off workshop that help the development team get to know the client’s business better. So far, we have used several approaches (e.g. user story mapping, product vision canvas, user journey) but sometimes they are just not enough from the developers’ perspective. Maybe Event Storming is then something for you.
Table of contents
You can read about techniques we use in Boldare here: Agile digital product development.
At these meetings we focus on goals, problems and personas. These are all extremely important to understand the business objective but don’t really give the developers an overview of what actually happens in the business nor how all these elements create a coherent product.
In 1974, a statistician named George Box stated that all models are wrong but some are useful. This sentence guided us in our attempt to learn how to use event storming. We wanted to adopt something useful, something that would help us to model a business but in an agile way. We focused on interactions and behaviors rather than on data structures and object states. The goal was to bring out what is actually important: dependencies, relations between behaviors, bottlenecks, etc.
In this article, I would like to share with you our experience from the first two event storming workshops that we held; events that helped us decide that this approach to modelling would be of use to us.
Event Storming Basics
Event storming is a workshop-based method invented by Alberto Brandolini to quickly find out what is happening in the domain of a software program. It has its roots in the DDD approach (domain-driven design), although you don’t need to know anything about DDD to use event storming with your team.
What is Event Storming for?
The obvious answer is, to create a business model that can be used during development, to get the big picture of the product environment, its needs and goals, and to assess its complexity. But there is more. Event storming supports group learning and is a fun way to integrate development and product teams. It helps if teams want to create alternative solutions together (especially interesting for startups) by visualizing and selecting them. Event storming may also be useful for teams with mature products to order the process and find out about bottlenecks and areas of conflict.
But above all it is about conversation. It’s a new way to share understanding about business objectives and product goals; a way of starting a discussion to discover gaps and hindrances.
>>> See our case study section
Why is event storming useful from a business perspective?
The simplest answer is: the better the development team knows your business domain, the more profound the initial analysis will be and the preparations to start the implementation phase will be more focused. That directly impacts the general quality of the product you are building, but also the overall cooperation between business and development teams.
It is also a great chance to learn about dependencies in the entire domain that might be less visible on a daily basis, but can significantly affect decisions made about the product, both on the technical and business ends.
Moreover, during an event storming session, the group has the opportunity to extract and discuss small pieces of the domain. And the less complexity at the beginning, the less complicated the problems are as the product development progresses.
How does it work? Event Storming guide
Organize the people
The key of a successful event storming session is to gather a bunch of people who know their stuff: developers that can ask questions about what should happen and business representatives who know the answers to those queries.
And also a facilitator to guide them through the process of exploring events, commands and grouping them into aggregates.
Organize the space
Essentials
It is extremely important to provide unlimited modeling space (either a wide wall for stickies or a very long piece of paper), tons of stickies in several colors, markers, some masking tape and finally, a relaxed atmosphere.
Make sure there is enough modeling space
A facilitator has to remain focused on the available area during the session, in order to ‘add’ to the modeling space before the participants notice that there is no more room to add a sticky note. If the participants stop for a moment they might lose momentum or (worse) a great idea and it will be difficult for them to get back on track.
Would you like to sit down? Not happening!
Brandolini advises that all tables and chairs should be removed for the session time. At our workshop, we decided to leave some of them so that there’s somewhere to put a coffee mug, and because we planned time for discussion of other issues.
However, I must admit that some people used the chairs during the storming session and it did feel that they were disconnected from the rest of group.
The Workshop
Before the workshop, all attendees were asked to read Alberto Brandolini’s short post about event storming basics, so that all of us could understand the general idea behind the event storming process.
We started the workshop with a short discussion on how we feel about event storming, ensuring all participants had the same essential knowledge of the technique, and also whether we see a use for it in our company. The possible options taken into consideration included checking if a problem actually requires a tech solution, designing, and feedbacking internal projects and processes.
We also thought about using this method as an alternative to a story map and developing a partnership with business representatives. We wondered how to determine product risks, gather data for technical recommendations, and how to realize the domain complexity (which sometimes is not that obvious at first glance). Quite a long list, isn’t it?
Then we briefly discussed the business that we were attempting to model. During the first session, two scrum masters from our team offered to act as business representatives for an in-house application for project management that our company created a couple of years ago. Next time, we decided to try the process with a simpler domain and one of the facilitators acted as business representative of a company that sells tickets for various events.
In both cases, the representatives were given time to make a short introduction. It was also useful to spend a moment to talk about the goal of the event storming sessions. Participants may be approaching it from many different angles, depending on the nature of the goal: mapping an existing product, a problem that needs to be solved, or searching for enhancements to a business process.
>>> Need custom software solution? Explore our agile-powered software services.
Step 1 – domain events
After this short introduction, we started with naming the domain events. We tried to answer the question ‘what happened’ in the context of our business domain.
The facilitator added the first post-it with a domain event to encourage everyone else. Then the group just ‘stormed’ the ideas, not focusing on the actual timeline. Some of the participants pointed out that it might be helpful to define the events marking the beginning and end of the business process, so that it would be easier for people to continue.
Remember to note the events in the past tense -> this helps participants to focus on the ‘what happened’ aspect. I believe it might be also important to highlight that participants should not focus on the actors who perform the actions while writing down the events (there will be place for that later in the process).
In my opinion, there’s no need to add all the events at this point. I feel that this part of event storming is designed to encourage people to collaborate and let them integrate. Especially given that some of the events will be thrown out during the next stages and new ones will be added.
Step 2 – commands
Why did this happen? This was the question that we started the next session block with and it was the right way to begin ordering the events chronologically. It is relevant at this stage to point out to the participants that command is something that people can do in the business domain, otherwise they may become stuck in places where actions are not triggered by users, but other factors instead.
At the end of the block, we spent a moment to reflect on events and commands. We concluded that if we would start from the commands, not from the events, probably focusing on new features and not on the cause and effect sequence. Starting from events helped us focus more clearly on the domain’s objective.
At this point, I noticed that adding the commands and other triggers raised more discussion than during the first part of the process. People were actually asking questions and thinking about what should happen, adding new events. Thus, for the next workshop I will definitely spend a bit more time on that phase.
Step 3 – other triggers
Events may have their roots in commands, but they might also be triggered by people, time, documents, or external or cascading events. During this session, we filled our model with these additional elements. Some stickies with commands were now replaced by notes representing an external event or time.
During the feedback session, the participants raised the issue that it would probably more effective for them if they knew in advance all types of triggers that we planned to use.
Step 4 – aggregates
As a next step, we grouped events and commands around aggregates. Each aggregate represented a specific business concept that had a local responsibility.
We marked those groups on our timeline. However, we kept in mind that marking the aggregates might break the timeline.
Step 5 – bounded context
After spending some time on aggregates, we discussed ubiquitous language. All people involved in the product development should speak the language of the domain (workshop, requirements, code, etc.) to support a shared understanding. Based on that, we should be able to distinguish between areas in which a word has a different meaning from the business perspective.
Bounded context is the setting in which a term appears, determining its meaning. Each context has a clear boundary and is consistent, having it own rules but still communicates with others.
The participants’ task was to draw boundaries between the multiple consistent models that would coexist in our test domain.
>>> Meet impact mapping - a method to help you manage goals, decide on priorities, and spot risks
The last two steps – determining aggregates and bounded context were the most difficult to understand for the participants. If facilitating a similar event, you may consider leaving a bit more space for discussion here.
As a group, we were also discussing how aggregates and bounded context may be useful for business people (as the concept is already quite familiar for programmers interested in DDD). The conclusion was that it can help them visualize their businesses and spot relationships between different departments.
>>> Interested in hiring a software development team? See our outsourcing guide!
Takeaways — Facilitation Tips and Tricks
The method is quite simple, so if a professional facilitator is unavailable to run the event storming session, a development team can conduct it on their own. In our case, the participating devs were confident that they could conduct something like this with their clients.
Questions and narration
If you are taking part in a workshop or actual session as a facilitator, your role is to help the participants stay focused and fully explore the domain. With this in mind, ask them questions such as:
- How does the process look on a regular basis?
- How would it behave in an ideal world?
- What could possibly go wrong?
- Who is affected by a particular action?
- How can we measure progress?
Reverse narrative is also good practice; for example:
- What must happen before a specific event can take place?
- What path led us to this moment?
Sticky notes
The color of the notes matters. I used a variety of light pastel colors but in practice it was difficult to tell the different colors apart at first glance here. Vivid colors are definitely a better choice.
Business domain
If you are just learning and not modeling an actual business, consider selecting a less complex business domain to practice with. That way, during the workshop, the group can focus on the event storming process and not the complexity of the business itself (though of course the business should be the focus of a real event storming session).
Language
Think about the language that you use to conduct the workshop. I was prepared to use English, which I consider to be more natural at work, so all my examples, slides and materials were in English. Imagine my surprise when the participants wanted to use Polish! Eventually, we managed but I might have overlooked a few details.
Legend
That leads us to creating the legend. It should be prepared in the same language as the workshop and put directly onto the wall. It would also be a great idea to create legend board rules and some follow-up questions (e.g. ‘command’ can be accompanied by ‘something that a person does’ and ‘why something happened’?)
>>> See advantages of outsourcing your software development to Poland!
When are we done?
At the end of the workshop, someone asked how do we know when the business model is ready. Unfortunately, there is no definitive answer but there are actions that we can take in order to gain a level of certainty:
- Make a short summary at the end of each block. If people worked in groups, ask them to sum up the discussed areas. After that check with the business as to whether they see any important aspects that have not been mentioned so far.
- Ask questions regarding the areas that were discovered. At some point there will be no more paths related to event or command.
- Make a map of the discussed areas. It could be a base for your user story map, but it also serves as an outline of covered topics.
>>> See how scrum can boost your software development projects
Conclusion
After the first workshop, we were left with two unanswered challenges:
- What can we do to encourage people to discuss things earlier? I noticed that only at the commands stage were we able to start a discussion about the actions (and there were no strangers present).
- How can we figure out a remote option to conduct this kind of workshop? Obviously, we are aware of the fact that the best way is to meet and cooperate face to face, but with international clients from all over the world, we need a reasonable solution for that.
Hopefully, the rising popularity of virtual reality will solve at least the latter of our two problems. Do you have any ideas on how to solve the first one?
Share this article:
