Behind the Scenes: 3 Collaborative Ceremonies for Better Development
Following a recent LinkedIn post, I wanted to write this article to describe 3 ceremonies that truly made an impact on me during one of my latest missions: Event Storming, Example Mapping, and Domain Storytelling.
These methodologies sit at the intersection of collaborative work and modeling. They allowed me to explore new dimensions in understanding and designing our product while strengthening our team synergy. Whether you are analyzing a complex domain, solving problems, or designing new features, each of these practices offers powerful tools to structure ideas, clarify requirements, and get everyone on the same page.
In this article, I will give you an overview of each ceremony and explain why they proved to be so effective for our team.
Event Storming
Created by Alberto Brandolini, Event Storming is a collaborative modeling method designed to quickly explore a complex business domain. The core idea is to identify domain events—the business events that describe what happens within a system or organization.
Complexity: Accessible to everyone, but it can become complex if the domain is very vast or if the team is new to collaborative modeling. You discover the full richness of the method through practice and participant diversity.
Duration: Typical session lasts 2 to 4 hours for a limited domain. For larger scopes, plan recurring workshops or a "Big Picture" session followed by targeted workshops.
Tools:
What makes Event Storming so engaging is its visual and inclusive approach. Team members (Product Owners, developers, designers, etc.) place sticky notes on a wall to map out events, actors, and their interactions.
Why I loved this method:
It promotes a shared understanding across different roles.
It quickly identifies areas of uncertainty or friction.
It provides a "Big Picture" view, which is essential for aligning stakeholders.
If you would like to learn more about Event Storming, here are some resources that have helped me:
🎥 Talk by Alberto Brandolini—DDD Europe 2019
📖 Book Introducing EventStorming — Alberto Brandolini
Feel free to share other resources or your feedback on this approach!
Example Mapping
Proposed by Matt Wynne, Example Mapping is a technique that helps teams define and clarify requirements using concrete examples. It is particularly useful during User Story discussions.
Complexity: Relatively simple to set up, especially if the team is already familiar with User Stories. The main challenge is formulating concrete examples and identifying ambiguity.
Duration: 45 minutes to 2 hours per User Story. Can be organized per task or grouped for several stories in a recurring workshop.
Tools:
How it works: Discussions are divided into 4 categories represented by different colored cards:
🟦 Rules: What the system must do.
🟩 Examples: Concrete cases illustrating the rules.
🟥 Questions: Areas of uncertainty.
🟨 Story: The specific need being discussed.
Why I loved this method:
It clarifies User Stories and encourages a real dialogue between business and tech.
It structures test cases and fixtures, making tests easier to read and aligned with business needs.
Every scenario becomes a true reflection of actual expectations.
Domain Storytelling
Domain Storytelling is a narrative method where you tell stories about business processes using a visual language. The goal is to model a domain through collaborative storytelling.
Complexity: Accessible, but requires some practice to tell precise stories and model interactions correctly. The involvement of end-users is essential.
Duration: 1 to 3 hours depending on the process complexity.
Tools:
In-person: Whiteboard and sticky notes.
Remote: Mermaid, Miro, or sequence diagram tools.
Why I loved it:
It highlights real workflows that are often ignored in traditional specifications.
It engages end-users, boosting their involvement.
It is accessible and understandable for everyone, including non-technical people.
Conclusion
While these 3 ceremonies are distinct, they share a common philosophy: collaboration, clarity, and stakeholder engagement. As a facilitator or team member, applying them allows us to break down silos and create a shared vision that goes far beyond simple written requirements.
If you have never tried them, I highly encourage you to experiment with them during your next projects. They might just transform the way you work and interact with your teams.
