You know what they say, “Two heads are better than one,” and the reason C.S Lewis believes so is that he thinks it is unlikely for two minds to “go wrong in the same direction.” That’s pretty much the basics of event storming: experts gathering in the same place to look for solutions.
Now, if you’re not familiar with event storming, you may be wondering why we call it the secret to successful tech products. But let’s start from the beginning and quickly make sure we are on the same page with what event storming is.
Event storming explained
Event storming is the brainchild of Alberto Brandolini, who, in 2012, created it as a rapid alternative to UML diagramming. It is a useful and rapid group modeling approach to domain-driven design. In other words, it is a workshop style tactic that brings multiple project stakeholders, developers and non-technical users, together in the same room to discuss and explore complex business domains.
Event storming is often associated with software development. But, make no mistake, it isn’t limited to software development but can also be applied to basically any technical or business domain.
It is a relatively new and still developing technique, and it has some slightly different approaches that often vary in small details. For example, some require more colorful sticky notes, while some are more modest. But, modifying the technique during the workshop is actually something that even its author recommends.
So, how event storming works? Event storming takes place as a facilitated workshop where everybody participates, but the facilitator is the one keeping everybody engaged and focused and guiding progress toward a final model of the domain.
Event storming starts with exploring domain events, walking through the domain model forwards and backward to make sure it covers everything. Next, the group starts to ad commands or triggers that will be the cause of the events it has identified, considering all sources of commands such as users, external systems, and even time.
Now, above all, it is really all about conversation and gathering ideas to find the best solutions for a product. By gathering developers, clients, and industry experts in the same room to share ideas and identify possible problems, business objectives, and product goals are genuinely understood by everybody.
Benefits of event storming
Now, let’s move further to why event storming has become such a widespread technique in tech organizations.
Event storming brings lots of benefits to the table, including being efficient and fun. But, perhaps the most significant advantage, from a business perspective, is that the better the dev team understands your business domain, the better the implementation phase and final product. Moreover, it also benefits the overall collaboration and communication between business and development teams at the end of the day.
But that’s not all! By gathering all key project stakeholders in the same room, literally or remotely, this technique is also:
- Fast
Collaboration and brainstorming during event storming sessions reduce the time it would typically take to create a complex business domain model. In other words, what used to take several weeks to get done can now be accomplished in a few hours during a workshop.
With business representatives, developers, and experts all in the same room, sharing ideas, everybody understands the project faster and more efficiently.
- Straightforward
Unlike UML, which is a more complex modeling language used to provide a standard way to visualize the design of a system, event storming is a much more straightforward process. It breaks down the process into simple and more common terms that both technical and non-technical project stakeholders can understand.
- Engaging
One of the primary purposes of event storming is to make collaboration between developers and business representatives and modeling fun. Unlike other modeling approaches, event storming is a hands-on technique to domain modeling that engages each person and invites communication and collaboration.
- Effective
Moreover, being enjoyable isn’t the only advantage of this approach. As it invites everybody to engage, it also often results in more valuable insights as participants are all actively participating in the process and offer their ideas, suggestions, and field expertise.
Event storming-step by step
Event storming has become a widespread approach in tech organizations around the world over the past years.
Over time, it has evolved and has been adapted by each team to cater to the unique needs of the product. Therefore, there are now many iterations and approaches you could take.
Now, we’re going to share the steps that make up the original basic outline of an event storming workshop. Yet, don’t worry, there’s plenty of room for adaptation of the process to your own needs and goals.
Step 1: Gather the right team
The original event storming technique relies on a larger group of people, at least six to eight people.
But who should you invite to the workshop to have the right team for this modeling approach? The creator of this technique, Brandolini, believes that the ideal people for this tactic are those people who know the right questions to ask and the ones who can answer them.
The best practice is to invite stakeholders from different areas of expertise, such as user experience, business, architecture, development, and IT.
Step 2: Provide unlimited workspace
The event storming approach is all about getting all ideas on paper (on color-coded sticky notes) and using them to map the domain’s modeling. But to do this, you and your team will need a lot of modeling space.
Traditionally, this approach implies applying sticky notes on a wall. So, if you have a large meeting room, there’s a lot of room to let ideas flow.
Step 3: Explore the business domain
Now, let’s get to the techy part. You and your team will have t identify the three main elements of this model: domain events, commands, and aggregates.
Step 4: Use domain-driven design
The event storming process can basically end after you add domain events, commands, and reactions. However, you can go further into this approach and combine it with the technique of domain-driven design.