What is Event Storming?

Event Storming is often used as a starting point to explore and learn about a business domain. Event Storming can be applied on 3 levels:

1.    Big Picture

2.    Process Modeling

3.    Software Design

In most cases you start with a Big Picture Event Storming workshop. The goal of Big Picture Event Storming is to assess the health of a whole line of business across corporate silos or explore the viability of a new startup business model. It helps a group create a shared state of mind of the vision of that domain of the company or to identify important problems that must be solved. During the process the participants will identify and agree on the main business events (called Domain Events) in a business flow and their order in time. After these domain events have been mapped on a timeline, you can proceed and add more concepts to the model as needed, such as

• Hot Spots (to visualize conflict, pain points, unanswered questions)
• Opportunities
• People (actors)
• Internal or External Systems (treated like a black box)
• Value (show where value is added or reduced in the flow)
• Bounded Contexts (essentially a system that encapsulates cooperative components  with clearly-defined boundaries that govern what can enter or exit the system. Inside the boundary, a Ubiquitous Language can be used freely. Outside of it, the language’s terms may have different meanings)

One common outcome of a Big Picture Event Storming Workshop is to identify the most important problem(s) to solve or the most important opportunity to address. This can be done by having the participants vote on the most important problems or opportunities.

The goal of the second level, Process Modeling Event Storming, is to assess the health of a single business process in the company or to design a new process. For existing processes, it helps the group create a shared state of mind of the current status of the process, finding bottlenecks and ambiguities. During this workshop you can add the following concepts as needed in addition to the ones used in Big Picture Event Storming:

• Policies (a reaction that says “whenever X happens, we do Y”, i.e. whenever [Event] then [Command])
• Commands/Actions (things that trigger the events, represents decisions, actions or intent. They can be initiated by an actor or from an automated process/policy)
• Read Model/Information (information needed by an Actor to take a given decision)
• UI mockups

You may reach a point where neither Big Picture or Process Modelling Event Storming is detailed enough to design new software. That’s when the third level, Design Level Event Storming kicks in. It’s a way to dive into a complex subdomain and collaborate around  software requirements. This finer grain design activity is more focused and technical using building blocks from Domain Driven Design. The goal of Software Design Event Storming is to design software that is based on a modern component based architecture. It helps development teams to collaboratively design the inside of a bounded context. During this workshop you may use the concepts mentioned above for Big Picture and Process Modelling Event Storming as well as the following concept:

• Aggregates/Components (aggregates are a Domain Driven Design pattern: a cluster or encapsulation of domain objects that conceptually belong together and can be treated as a single unit, e.g. a purchase order or a motorcycle. It reduces the interface of an application segment and constrains access to internal objects. Treated like white box.)
• UI (sometimes a read model is not enough to convey the information. Layout, images and so on can be captured by wireframes too.)

The domain events and the timeline are the foundation of Event Storming. The other concepts mentioned above are applied as needed.

From Event Storming to User Stories

Event Storming is a great starting point but most agile teams are used to work with User Stories in a Product Backlog. How do you go from a business process documented using Event Storming to actionable User Stories that can be estimated, prioritized and planned into a Sprint? Some teams may be able to start coding after a few Software Design Event Storming sessions but many Product Owners and developers like the structure of a Product Backlog or User Story Map since it enables a smooth value based iteration planning among many other benefits. The Product Owner is also interested in predictability and wants to be able to control and predict the outcome in the upcoming sprints.

One way of looking at it is to start from the key domain events and commands identified during the Event Storming workshops. Many of these events/commands are related to user actions and the events can be treated as the backbone in a User Story Map, i.e. they can be the epics or user journey steps in the User Story Map. The team can then continue working according to Scrum and User Story Mapping by adding user stories to each step/Epic. Commands can be used as a source of inspiration for writing the user stories. The team then estimates the work involved in each user story and knows what stories they can complete for upcoming sprints or releases. The team and the Product Owner prioritize the User Stories as usual in order to deliver more value more quickly and the content of each release/sprint is visualized.

Facilitating Collaboration, Focus and Speed While Working Remotely

Many teams are working remotely today so stakeholders and team members cannot gather in front of a huge whiteboard and place sticky notes on the whiteboard. We need some kind of online collaboration tool. One possible solution is to use the tool Qlerify. Qlerify bridges the gap between Event Storming and an actionable product backlog in the developers’ planning tool. The process modeling engine in Qlerify is extremely fast and allows you to visualize the discussion in real-time and supports methods/practices such as Event Storming, User Story Mapping, Product Backlogs, Agile Data Modeling and Business Process Modeling. It also includes social collaboration features and API-integration with Jira Cloud to instantly transfer content to Jira. Try for free at https://app.qlerify.com/signup.

If you would like to know more, there are some excellent blogs describing Event Storming and User Story Mapping in detail. Here are some great blog posts:

User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton (book on Amazon)

User Story Mapping: by Jeff Patton (original blog post)

Introducing Event Storming by Alberto Brandolini (original blog post)

Introducing Event Storming by Alberto Brandolini (Leanpub book)

Domain-Driven Design Distilled by Vaughn Vernon. (Chapter 7 introduces Event Storming as an acceleration and management tool for DDD)

Event Storming Cheatsheet by Wolfgang Werner (good cheat sheet for a quick introduction into the topic)

If you liked this post, please share it!