How event storming can help you understand your product’s foundation and achieve its goal faster
Not very long ago, organizations who wanted to learn more about their business systems and software products had to resort to technical modeling approaches or the traditional trial-and-error. While there’s still a time and place for these approaches, the modern, collaborative environment calls for faster, interactive measures that get the entire team involved.
One of these is event storming – an interactive approach that can help you design event-driven systems, understand the business processes that affect your domain, and come up with smart ideas by getting the entire team, and the stakeholders, involved.
But how exactly does event storming work, and how should you organize one? Read on to find out.
What is event storming?
An event storming is a facilitated workshop where the entire development team participates. It was first suggested by Alberto Brandolini in 2012, as an alternative to UML diagramming, and it’s based on the principles of domain-driven design (DDD):
· Domain and domain logic are at the core
· Complex designs should be based on models of the domain
· Technical teams should always collaborate with domain experts to improve the product and address domain-related problems as quickly as possible
The purpose of event storming is to bring developers and non-technical users together in the same room, where they can interact and explore complex business domains. Since it’s based on a collaborative, interaction-driven approach, event storming doesn’t require a computer – just a lot of post-its (we’ll get to those later). Event storming is meant to be fun, engaging, and help the team understand the product while at the same getting to know each other better and develop team spirit.
Although event storming shouldn’t be perceived as a substitute for a UML diagram, it’s a much quicker alternative that accelerates the development process.
Benefits of event storming
The biggest benefits of event storming stem from the fact that everyone works together in the same room and focuses on the same goal: understanding the software and the problems that it’s meant to solve.
· Simplicity. Unlike more complicated approaches, such as UML diagramming, event storming is much more straightforward. Both technical and non-technical experts can understand how it works so that you won’t be needing lengthy introductions or extensive planning.
· Speed. Event storming helps you create an event storming model within just a few hours, unlike other approaches, which may take days or even weeks.
· Fun. Event storming is meant to be engaging for everyone involved. Everyone can interact and share their insights, even if they have no experience in software development.
· Efficiency. Once the event storming is over, you are left with actionable points that you can then easily implement.
· Insights. Event storming is something that you constantly learn from. At the end of the workshop, your team has gained valuable insights that will help them know the industry and develop better products in the future.
· Team building. Working together and interacting more than usual gives your team the opportunity to know each other better. Boosting team cohesion increases the chances of them working successfully together on future projects.
What do you need for event storming?
Fortunately, you don’t need too many things for a successful event storming. It only comes down to three key points:
Bring together the right people.
People are the essence of event storming, and choosing the right group can influence its outcome. For best results, the group should be split into two categories: people who ask the questions, and people who can answer them. That means you’ll have to include both experts with technical knowledge (developers, IT experts, etc.) and non-technical experts who are familiar with the software domain. You may also consider bringing in clients, who are representative of the user experience and will help you look at things from their perspective.
Some argue that domain experts are essential in event storming, and while it’s true that their insights are extremely valuable, organizations who don’t have access to domain experts can still try event storming and still gain some domain knowledge without them.
Ideally, you should have at least eight people taking part in the workshop, plus a moderator to lead the discussion.
For event storming, you need a relatively large room with plenty of standing space. Also, make sure the walls are empty, because you’ll be sticking plenty of notes on them. Even storming was designed as a real-life approach, but if you work with remote teams and can’t get everyone together, there are ways to plan it virtually.
Like we said before, you don’t need computers and tech tools to carry out event storming. You do, however, need sticky notes in seven colors, each standing for a different concept in domain-driven design:
After event storming begins, the moderator will place the sticky notes on the wall, grouping them together depending on the context and chronology.
The phases of event storming
Although event storming may seem chaotic at first, there is a structure to it. The workshop starts with identifying the domain events – those events that trigger a reaction, always represented on the post-it at the past tense. Then, the team has to identify the action or command that caused the event, focusing on cause and consequence, and using the present tense. Next, they will focus on aggregates, which are responsible for decision-making. At this stage, they also decide how different commands should be grouped together and handled by the same aggregate. Soon, the wall will be filled with groups of sticky notes, which will allow your team to see separate processes, as well as the system as a whole. During the workshop, you will also discover test scenarios, users, and goals, and incorporate them into the model. In the end, you’ll have a detailed context map.