logo
logo
Sign in

From Event Storming to User Stories

avatar
Nikolaus Varzakakos
From Event Storming to User Stories

Event Storming is commonly used as a starting point to explore and understand a business domain. It can be applied at three different levels:


  • Big Picture
  • Process Modeling
  • Software Design


In most cases, the starting point is a Big Picture Event Storming workshop. The purpose of this workshop is to evaluate the overall state of a business line across different departments or to explore the feasibility of a new startup business model. It helps a group establish a shared understanding of the company's domain vision or identify critical issues that need to be addressed. During the workshop, participants collaborate to identify and agree upon the key business events (referred to as Domain Events) within a business process and arrange them chronologically. Once these domain events are mapped on a timeline, additional concepts can be incorporated into the model as necessary, 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)


A common outcome of a Big Picture Event Storming Workshop is to identify the critical problem(s) that need to be solved or the significant opportunity that should be pursued. This can be accomplished by allowing participants to vote on the most important problems or opportunities.


The objective of the second level, Process Modeling Event Storming, is to evaluate the effectiveness of a specific business process within the company or to design a new process. In the case of existing processes, it assists the group in developing a shared understanding of the current state of the process, identifying bottlenecks and areas of ambiguity. During this workshop, the following concepts can be added as necessary, in addition to those used in the Big Picture Event Storming session:


  • 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


There may come a point where both Big Picture Event Storming and Process Modeling Event Storming lack the level of detail required for designing new software. This is where the third level, Design Level Event Storming, becomes relevant. It provides a way to delve into a complex subdomain and engage in collaborative discussions regarding software requirements. This design activity focuses more precisely on technical aspects and utilizes building blocks from Domain Driven Design.


The primary objective of Software Design Event Storming is to design software that is based on a modern component-based architecture. It facilitates the collaborative design of the internal components within a bounded context for development teams. During this workshop, you can employ the concepts mentioned earlier in Big Picture and Process Modeling Event Storming, as well as the following concept:


  • Aggregates/Components (aggregates are a pattern derived from Domain Driven Design: a grouping or encapsulation of domain objects that are logically related and can be treated as a unified entity, such as a purchase order or a motorcycle. They help streamline the interaction within a specific part of an application and restrict access to internal objects. Think of them as transparent containers that enable controlled manipulation.)


The core elements of Event Storming are the domain events and the timeline. They form the foundation of the process, while the additional concepts mentioned earlier are incorporated as required.


From Event Storming to User Stories

Event Storming serves as a valuable starting point, but many agile teams are accustomed to working with User Stories in a Product Backlog. So, how can we transition from documenting a business process using Event Storming to actionable User Stories that can be estimated, prioritized, and planned into a Sprint?


While some teams may start coding after a few Software Design Event Storming sessions, many Product Owners and developers appreciate the structure provided by a Product Backlog or User Story Map. These tools facilitate smooth, value-based iteration planning, among other benefits. Additionally, the Product Owner seeks predictability and wants to exercise control over and forecast the outcomes in upcoming sprints.


One approach is to begin with the key domain events and commands identified during the Event Storming workshops. Many of these events/commands are associated with user actions and can serve as the backbone of a User Story Map. They can be treated as epics or user journey steps in the User Story Map. The team can then follow Scrum and User Story Mapping practices by adding user stories to each step/epic. They estimate the work required for each user story and gain clarity on which stories can be completed in upcoming sprints or releases. The team and the Product Owner prioritize the User Stories as usual, aiming to deliver greater value in a more efficient manner. The content of each release/sprint is visualized and made transparent.


Facilitating Collaboration, Focus and Speed While Working Remotely

In today's remote working environment, many teams face the challenge of stakeholders and team members being unable to physically gather around a whiteboard and use sticky notes. Fortunately, there are online collaboration tools available to bridge this gap. One such solution is Qlerify. Qlerify serves as a tool that connects Event Storming with an actionable product backlog within the developers' planning tool.


Qlerify features a powerful process modeling engine that operates at remarkable speed. It allows you to visualize discussions in real-time and supports various methods and practices, including Event Storming, User Story Mapping, Product Backlogs, Agile Data Modeling, and Business Process Modeling. Moreover, Qlerify incorporates social collaboration features, fostering effective teamwork and communication. Additionally, it offers API integration with Jira Cloud, enabling seamless content transfer to Jira for streamlined project management.


If you're interested, you can try Qlerify for free by signing up at https://app.qlerify.com/signup. Qlerify empowers remote teams to collaborate efficiently and effectively, overcoming the challenges of distance and facilitating the successful execution of projects.


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)

collect
0
avatar
Nikolaus Varzakakos
guide
Zupyak is the world’s largest content marketing community, with over 400 000 members and 3 million articles. Explore and get your content discovered.
Read more