Search
  • Nikolaus Varzakaos

From Event Storming to User Stories

Updated: Nov 2






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 Modelling

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)

  • Pivotal events (the most significant domain events that are a great source of information)

  • Swimlanes (separate the whole flow into horizontal swimlanes, assigned to given actors or departments)

  • 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 Modelling 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)

  • UX 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.)


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 than 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 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. 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. Qlerify is a user-friendly co-editing workspace with support for powerful models 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 ALM tools, such as Jira.



Maximum Speed and Simplicity

One benefit of using Qlerify is that it enables the creation and documentation of content in real-time during the event storming workshops and mapping sessions and instant transfer of content to Jira with the click of a button – no need for a team member to enter all the gathered workshop data into Jira manually. Agile teams can move straight into sprint planning immediately after the mapping sessions!



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)



91 views0 comments

Recent Posts

See All