The Communication Problem

Experience from numerous software projects shows that achieving effective communication between domain experts and engineers is still a major challenge. Traditional methods, such as roundtable meetings or separate interviews, are often ineffective and limit business involvement. As a result, system solutions are typically shaped by a limited understanding of business needs among technical teams, leading to systems that fall short of expectations. Event Storming is designed to bridge this communication gap between business and engineering, enabling full involvement from business stakeholders in the modeling process.

‍

The Silo Problem

Another common problem in many organizations stems from working in silos. Here, we are not referring to the gap between business and engineering but rather to the gaps between different parts of the business itself. The issue is that domain experts typically understand their own department well but have little or no insight into what’s happening in other departments. This often leads to duplicate work, miscommunication, unnecessary delays, and many other forms of friction.

We are not suggesting that all silos are bad. Usually, they exist for good reasons, and we are not advocating for their removal. However, Event Storming can be a game-changer when it comes to aligning silos, fine-tuning how they work together, and helping all departments see the bigger picture. In just a few hours, Event Storming can uncover bottlenecks and misunderstandings that have been harming the organization for years. It can help large groups of people agree on shared challenges and reach consensus on priorities. The result? Often dramatically improved business performance, a sharper focus on the right problems, and system designs that support the way the business actually operates.

‍

Why Event Storming Is So Powerful

Event Storming is a workshop format that solves both the communication problem and the silo problem at once! It involves from a few up to 20 persons in the same room in front of a white board or using a digital tool such as Qlerify. Event Storming is based on a simple idea: the Domain Event. This is an event in a business process, described in past tense—like “order placed.” It’s easy for everyone to understand, making it simple for business people to join the conversation.

In an Event Storming workshop, domain experts and developers work together to explore how a business really operates. Domain events are mapped out together and arranged on a timeline. Once the basic flow is clear, more details are added—like: who’s involved, what systems are used, what are the business rules, which are the main pain points and where are there opportunities and ideas for improvement.

The best part? Event Storming is flexible. You can adapt it to fit your goals and the people in the room.

‍

Three Levels of Event Storming

Event Storming can be used in different ways, depending on your goals. It operates at three distinct levels:

1. Big Picture (6-20 participants)
   • Gives a high-level overview of how the organization works, helping to identify major pain points, problems, or opportunities for improvement.
   • Captures Domain Events, People, Hotspots (Problems and Opportunities) and Systems.

Read more about Big Picture Event Storming

1. Process Modeling (4–8 participants)
   • Zooms in on a specific business process, mapping it out step by step. This level includes exploring alternative flows.
   • Captures same items as Big Picture plus: Policies, Commands and Read Models.

Read more about Process Modeling Event Storming

1. Software Design (3–6 participants)
   • Lays the groundwork for system development.
   • Captures the same items as Process Modeling plus: Aggregates

Read more about Software design Event Storming

‍

Event Storming with AI – A Leap Forward in Productivity

Event Storming just got a major upgrade with AI-powered automation in Qlerify. Instead of starting from a blank canvas, you can now generate a full Big Picture, Process Model, or Software Design tailored to your specific needs in seconds. When working with Event Storming at the Software Design level, the AI can instantly create commands and aggregates—automatically grouping commands and events around aggregates. This means spending less time on setup and more time collaborating with your team to refine and perfect your model.

‍

Event Storming with Qlerify

Here, we will guide you through the detailed steps of conducting a Software Design-level Event Storming session in Qlerify with the help of AI. This example will hopefully also provide you with enough knowledge to apply the same approach to Big Picture and Process Modeling.

Log in to Qlerify or sign up for an account using the link in the footer, create a new project (using the buttons available after logging in), and then follow this step-by-step guide.

‍

Step 1: Create a new Workflow

Create a new, empty workflow and open it. You should see a view similar to the image below. This is your blank workspace, where you can add a starting point, generate a workflow with AI, or review and update settings. You can also invite team members to collaborate on the project.

For more details about this view, click the question mark icon.

Step 2: Review card types

Open the workflow Settings by clicking the cogwheel above the workflow diagram and selecting the Cards tab.

When you create a new workflow in Qlerify, a default set of card types is provided. These can be used for Big Picture, Process Modeling, and Software Design-level Event Storming. You can add, update, and remove card types based on your needs. The default setup includes the following card types:

The card types "Given-When-Then" and "User Story" are not typically part of standard Event Storming. However, if you want to enhance your Software Design session, feel free to include Given-When-Then (GWT). In this example, we will leave them out for now.

Go ahead and update the Card Type Settings:

• Show in backlog: Under this heading, make Problem and Opportunity visible in the backlog by clicking the eye icon to remove the strikethrough line. This allows us to prioritize Problems and Opportunities at the end of the session and plan them into iterations.
• Use AI: Under this heading, untick Given-When-Then and tick Problem and Opportunity. This ensures that AI generates Problems and Opportunities instead of GWTs.

• Command: Under this heading, make sure the type Command is selected.
• Aggregate Root: Under this heading, ensure the type Aggregate Root is selected.
• Rename the card type Aggregate Root to only Aggregate (because we are doing Event Storming and not building a full Domain Model). Update the description to:
  • "The aggregate that the command is invoked on in this step of the process."

Note: There are two special card types (Command and Aggregate Root) that we use to be able to group Commands and Events around Aggregates at the end of our Software Design session.

Note: If you think Aggregate is a confusing term, feel free to change it to something like Entity or Information Object. ‍

Finally, you can review—and update if needed—the descriptions of each card type by clicking Show description. These descriptions are used for AI prompting.

Step 3: Generate with AI

You can generate full workflows with AI whenever you start with a blank canvas by clicking "Generate Workflow with AI". Once you started adding events to a workflow, this button will no longer be visible.

There are several large language models (LLMs) available for you to use. In this example, we used ChatGPT-4o. You can select your preferred model (LLM) from several options in the workflow Settings (under the AI tab).

We’ll start with a simple prompt from the list of examples displayed when entering your prompt. Feel free to modify it to make it more detailed if you want:

• Example of a simple prompt: "A CRM process used by Salesforce."
• Example of a more detailed prompt: "A CRM process used by Salesforce, including the steps: Lead created by Sales Person, Lead qualified by Sales Manager, Opportunity created by Sales Person, etc."

Next, deselect "Generate Data Models with AI" (these are used for Event Modeling and Domain-Driven Design) and click "Generate Workflow."

‍

Once the AI generation is complete, you may end up with a result similar to the example below, though the variation can be significant.

Step 4: Collaborate

Now, collaborate with your team by going through the workflow step by step to ensure each step is correct. You can invite all your team members to Qlerify for real-time co-editing. Sometimes, it’s best if one person navigates the tool while others contribute verbally. This depends on the situation and your facilitation style.

Start with the first event, "Created Lead," and follow these steps:

1. Check Event: Is the event correct, or should another event come before it? Qlerify makes it extremely fast and easy to rearrange events using drag & drop. You can also manually add new events or generate them with AI using the menu that appears under a selected event.

2. Check Actor / Role: Instead of yellow cards, Qlerify uses swimlanes to represent actors or roles, making it easy to see each participant’s involvement in the process. If the swimlanes are incorrect, you can:
   • Rename swimlanes
   • Reorder swimlanes
   • Add new swimlanes
   • Drag and drop events between swimlanes

3. Open the Sidebar: If the event (in this example, "Created Lead") is correct, select it and open the sidebar using the icon on the right side of the window (if it’s not already open).

4. In the sidebar, update the Command name if necessary. If you’d like to modify the AI-generated Aggregate name, you can do so as well.

Note: In Software Design Event Storming, each event should correspond to one state-changing command that operates on a single aggregate. If an event is not state-changing, consider leaving it out. If one event corresponds to multiple commands, split it into multiple events.

‍Note: When updating the Aggregate, a combo box will appear, allowing you to generate entities. At this stage, we will not generate entities but instead use free text for the Aggregate name. For more details on using Entities, see our articles on Domain-Driven Design and Event Modeling.

5. Identify Hotspots (Problems and Opportunities): What are the problems and opportunities in this step of the process? Discuss with your team. Add new Problems or Opportunities manually or with AI. You can revisit and iterate over all cards later.
6. Decisions / Policies: In the original Event Storming method, a policy (purple card or “lie detector”) must be placed after each event. In Qlerify, we have chosen to use Decisions / Policies only when there is a branching point in the process. Some might think this is incorrect, but in our experience, this approach works well in practice.
   • Add decisions only when there is a branching point—don’t overdo it.
   • We recommend modeling the most valuable path first (the "happy path") before adding too many branches.

7. An Alternative Approach to Decisions: Sometimes, it’s easier to use another approach to decisions. Instead of placing a decision after an event, you can add a Given-When-Then (GWT) condition to the next event to specify what is required in order for the workflow to continue.

Step 5: Iterate

Now, repeat Step 4 for each event, refining your workflow iteratively. You don’t need to complete everything in a single session—you can revisit your workflow and refine it in separate sessions with different groups of people.

Things to Keep in Mind:

• Begin by completing the most valuable path (the "happy path"), then move on to the most important alternative paths.
• In Qlerify, events are always displayed either fully to the left or directly after a vertical divider. All other events will be positioned one step to the right of their parent event. Although this might take some time to get used to, it makes modeling extremely fast once you’re familiar with it. You'll never waste time manually rearranging lines and boxes again!

• You can introduce new starting points by clicking "+ Add start point" under the diagram. These can be merged with existing events as needed.

• Click "+ Add group" once to create a new group or twice to add two groups separated by a vertical divider. Align events horizontally by stacking them at the beginning of a group. We recommend using Groups to divide your canvas into separate Phases or Stages.

‍

Step 6 (Optional): Read Models and Commands

Qlerify offers powerful support for defining Entities, Read Models, and Write Models. For more information on these features, see our articles on Event Modeling and Domain-Driven Design (links in the footer).

‍

Step 7: Aggregates View and Bounded Contexts

Qlerify provides an instant view of Commands and Events grouped around Aggregates. This view is located under the workflow diagram in the Domain Model tab.

The view might look similar to the image below. Each command (the blue boxes) has its corresponding event on the right side, aligned at the same height. Here, you can see a summary of your aggregates and the operations available on each one.

The next step is to assign a bounded context to each aggregate. To do this, click "Select bounded context." After selecting a bounded context, the view may look something like this:

‍

‍

Step 8: Wrap Up

You have now captured the workflow and identified bounded contexts, aggregates, commands, actors, problems, and opportunities (and maybe even some GWTs). You have built the foundation of the domain model.

Now, you can further refine your model by specifying entities, read models, and write models in detail. For more information, see our articles on Event Modeling and Domain-Driven Design.

As a final step, review the identified problems, opportunities, and GWTs, and plan them into iterations.

You can use either the Backlog or the User Story Map view. In this example, we use the User Story Map, which is located in a tab under the Workflow.

1. Assign Problems, Opportunities, User Stories, or GWTs to releases.
2. Use the filter above the diagram to focus on one or multiple releases and see how the planned improvements impact the end-to-end workflow.