After a wild, fast-paced Event Storming session, the sticky notes are everywhere, the walls are covered, and everyone’s brain is buzzing with insights. But now comes the crucial part - how do you close the session, ensure nothing is lost, and translate all that chaos into something actionable for the development team?
Let’s walk through how to wrap up an Event Storming session and ensure it leads to real architectural and product decisions.
Reflect and Summarize
It’s easy to get caught up in the excitement of discovering new patterns and revealing insights, but once the session is winding down, you need to bring everyone back together and refocus. You want to make sure that the energy doesn’t fizzle out and that participants leave with a shared understanding of the domain and what comes next.
-
Reflections: Ask the group what stood out to them. This is where you’ll uncover any final insights or lingering questions. A simple question like, “What surprised you the most today?” will encourage reflection and allow participants to process what they’ve just learned.
-
Summarize Key Findings: Go over the most significant discoveries from the session. Highlight the bounded contexts, the aggregates, and the pain points. This is your moment to create clarity on the key takeaways. Give people something to walk away with, whether it’s an overall domain map or a list of questions to resolve later.
-
Align on Next Steps: A great Event Storming session won’t just end with a pile of sticky notes. Before wrapping up, it’s important to align the team on the next steps. Ask, “What’s the most important thing to focus on now?” and decide together what to do next.
Make sure that everyone knows how their contributions fit into the bigger picture, and how the insights from the session will influence the development and architecture process moving forward.
Turning Stickies into Structure
You’ve got a wall full of sticky notes, but what happens next? The key is to preserve all the hard work that went into that session and turn it into something tangible that the team can refer back to. Here’s how to keep the insights alive and actionable:
-
Take Photos or Videos: Before anything gets moved or cleaned up, snap photos or take videos of the entire wall. You’ll be able to reference this later, and sometimes, seeing the entire wall in one go can help uncover even more insights after the session.
-
Create a Digital Version: Transfer the sticky notes into a more permanent format. Whether it’s a digital mind map, a domain model, or even a simple flowchart, make sure you capture the information in a structured way. Tools like Miro, MURAL, or Lucidchart are great for this. If you’re using a whiteboard or wall, ensure someone captures the key points, whether through photos or written summaries.
-
Document the Findings: Besides the map itself, create a summary document that explains the results. This should include key decisions made, unresolved questions, and areas that need further exploration. The document will serve as a guide to help the team maintain focus on the most important elements of the system as they start building.
Translating Insights into Actionable Requirements
This is the most crucial part: how to turn all this visualized domain knowledge into something that a development team can use. After all, the goal of Event Storming isn’t just to “discover” the domain, it’s to translate that knowledge into concrete development work.
1. Identify Actionable Events
Look at your domain model and extract the core events. These are the key business processes and interactions that the development team needs to model. For instance, if “Invoice Sent” is a crucial event, then you know this will need a service or feature that triggers an invoice to be sent.
Once you’ve identified these core events, break them down into smaller components, such as:
- What systems or services are involved?
- What data needs to be processed?
- What are the user flows for each event?
These insights can directly translate into user stories or technical tasks that the development team can start implementing.
2. Define Bounded Contexts and Aggregates
The boundaries you defined during Event Storming are gold mines for architectural decisions. Each bounded context and aggregate can become the foundation for services, microservices, or modules within the application.
For example, if the Payments bounded context is defined, it might become a separate service responsible for managing all payment-related activities. From there, you can start defining the services that interact with it, the APIs, and the responsibilities of each service.
Map these boundaries into:
- Service definitions
- Database schema or entities
- Microservice boundaries
- Team responsibilities (who owns which part of the system)
These elements will help shape the system’s architecture and clarify the development team’s responsibilities.
3. Prioritize Pain Points and Bottleneck
Look for the pain points you uncovered during the session - those places where confusion, inefficiency, or unclear processes emerged. These should be flagged as areas that need immediate attention. Prioritize these pain points by their impact on the business.
For example, if a certain event like “Payment Failed” keeps triggering confusion or delays, it’s likely a high-priority item for the development team to address. These insights can directly shape the backlog by influencing what gets built first.
4. Use the Map for Backlog Refinement
Once the Event Storming session is wrapped up, take your visual map and refine it into a backlog. Break the domain events, aggregates, and pain points into user stories or technical tasks that make sense for the development team.
For example, you might translate the “Invoice Sent” event into a user story like:
- As a system, I need to trigger the sending of an invoice to the customer when a reservation is confirmed, so that I can ensure timely billing.
Incorporate the identified services, events, and user flows as part of your technical user stories and acceptance criteria for future sprints.
5. Create a Feedback Loop
Once development starts, continue to circle back with the business and technical teams to ensure you’re on track. Event Storming isn’t just a one-time thing. It’s about continuous learning and adapting the architecture as new insights emerge.
This feedback loop is essential to keeping the system aligned with the business, and you can do this by running mini Event Storming sessions periodically to revalidate decisions and assumptions.
Turning Insights into Reality
Event Storming doesn’t end with the session. The real value lies in how you preserve the insights, organize them, and translate them into actionable development work. By turning those chaotic sticky notes into a structured map, and then into a series of actionable tasks, you’re creating a shared understanding that will serve as the foundation for your entire system.
Remember, the goal of Event Storming is to facilitate conversations, clarify assumptions, and provide actionable insights, not just to create a beautiful diagram. So, as you close your session, take pride in the fact that you’ve not only mapped the domain but set the stage for building a system that truly meets the business needs.
So, take a step back, snap that last photo, and start translating your findings into action. The work begins now.