From Event Storming to User Stories

In this article, we describe how you can use Event Storming for your new development project and then apply User Story Mapping to add user stories and plan them into sprints or releases. Event Storming is a very powerful workshop facilitation tool that improves collaboration between IT specialists and business people.

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 Modeling

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 to create a shared state of mind of the vision of that domain of the company. 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.
• Actors/Agents.
• Internal or External Systems.
• Value: To 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-definedboundariesthat 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.

The goal of the second level, Process Modeling Event Storming, is to assess the health of a single business process in the company. 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:

• Policies: A reaction that says “whenever X happens, we do Y”, i.e. when an event automatically triggers a command.
• Commands/Actions: Things that trigger the events, represent decisions, actions, or intent. They can be initiated by an actor or from an automated process/policy.
• Query Model/Read Model/Information: Information needed by an Actor to make a decision or send a command.
• UX mockups.

You’ll reach a point where neither Big Picture nor Process Modeling Event Storming is detailed enough for software design. 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 clean and maintainable Event-Driven software. It helps development teams to collaboratively design the inside of abounded context. During this workshop you may add the concepts mentioned above for Process Modeling Event Storming as well as the following concepts as needed:

• Aggregates: 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, a playlist, a car. It reduces the interface of an application segment and constrains access to internal objects.
• Business Rules.
• Constraints.

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

Adding User Stories

Event Storming is a great starting point but most agile teams are used to working 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 content 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. 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 Event Storming, User Story Mapping, Product Backlogs, Agile Data Modeling, social collaboration, and API-integration with ALM tools, such as Jira.

Watch the Qlerify demo video to better understand how this tool works.

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!

Another benefit is that Qlerify is built for remote collaboration and is very easy to use. All team members can co-edit content in one single workspace and the entire workspace is distributed in real-time so everyone can see all contributions and add comments and votes.

Conclusion

Qlerify enables remote teams to go from a workshop to an actionable product backlog in Jira in record time - your developers can start coding immediately after the workshop!

If you would like to know more about Event Storming and User Story Mapping, there are excellent blogs describing these concepts. For example:

• 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 Stormingby Alberto Brandolini (original blog post)
• Introducing Event Stormingby Alberto Brandolini (Leanpub book)
• Domain-Driven Design Distilledby Vaughn Vernon (chapter 7 introduces Event Storming as an acceleration and management tool for DDD)
• Event Storming Cheatsheetby Wolfgang Werner (good cheat sheet for a quick introduction to the topic)