Wait, so I just stick Post-it notes on a wall and call it a workshop? Yep. Well, kind of.
If you’ve been invited to an Event Storming session, you might be wondering what you’re in for. Maybe you assume it’s just another meeting where tech folks talk in code while you nod along, pretending to follow. Good news: that’s not the case. Event Storming isn’t a techie thing. It’s about business, and you, the domain expert, are the most valuable person in the room.
What’s This All About?
Event Storming is a collaborative workshop where we explore a business process by mapping events - things that happen - in a visual way. Think of it like piecing together a crime scene. Each sticky note represents a clue, and together, we reconstruct what really goes down in your business. No need for fancy diagrams or technical jargon, just pure storytelling.
Instead of endless meetings where half the room checks their emails, this is an active, fast-paced session. Sticky notes fly onto the board as people uncover hidden steps, forgotten edge cases, and broken processes. It’s not just about documenting what works - it’s about revealing what’s broken and why.
Why Should You Care?
Because you own the story. Developers might build the system, but it’s your process they’re trying to model. If they get it wrong, software gets in the way instead of helping. Your insights make the difference between software that works and software that sucks.
Imagine a hotel reservation system where no one mentioned that guests sometimes request room changes after check-in. Now, the system has no way to handle that, and front desk staff are forced to hack around it. That’s the kind of thing Event Storming helps prevent.
How to Be a Rockstar Participant
You don’t need to know tech. You just need to know your business. Here’s how to contribute effectively:
1. Tell the Story, Don’t Design the System
Stick to what happens in your world. What kicks off a process? What happens next? What could go wrong? No need to think about how software should handle it, just describe reality.
It’s like explaining your job to a new hire. They don’t need the history of your company’s policies; they need to know what actually happens on a busy Monday morning.
2. Be Specific, Avoid Abstractions
“We handle reservations” is vague. “A guest books a room, then cancels an hour later” is gold. Concrete examples help uncover nuances that generic statements miss.
A useful trick: If what you’re saying could fit any company, it’s too vague. If it only makes sense in your business, you’re on the right track.
3. Call Out the Exceptions
Things rarely go smoothly in real life. Does an approval sometimes get stuck? Do customers abandon carts? These edge cases are often where the real business logic hides.
A canceled reservation is easy to model. But what if a guest cancels, then changes their mind five minutes later? Can they undo it? Does the system refund automatically? That’s where the real complexity lives.
4. Push for Clarity
If something sounds unclear, ask. If a term is fuzzy, challenge it. Precise language prevents misunderstandings later when code gets written.
“Customer” could mean a guest, an account holder, or a company booking multiple rooms. If no one defines it, developers will guess. And they might guess wrong.
5. Don’t Fear the Chaos
Event Storming sessions start messy - sticky notes everywhere, overlapping ideas, debates. That’s normal. The goal isn’t to be neat; it’s to reveal complexity and refine understanding.
If it looks too clean, something’s missing. A good session feels like controlled chaos - energy, discussion, and a wall that looks like a crime investigation.
The Three Problematic Participants
Not everyone helps move the session forward. Sometimes, well-meaning participants end up slowing things down. If you recognize yourself in any of these, don’t worry, awareness is half the battle.
The Philosopher
Meet Greg. Greg loves abstract discussions. Ask him what happens when a customer cancels a reservation, and suddenly, we’re talking about the philosophy of commitment and decision-making. Meanwhile, nobody knows what actually happens in the system. Greg means well, but if you find yourself drifting into theory, bring it back to real-life events.
Greg isn’t useless - his thinking is valuable, but not at this stage. Event Storming is about discovering how things work, not why people behave the way they do.
The Gatekeeper
Then there’s Lisa. Lisa’s been at the company for 15 years and believes that knowledge is power. She answers questions vaguely, insisting, “It’s complicated” or “You wouldn’t understand.” Lisa, we need you. But we need the details, too. If you catch yourself withholding info, remember, this session isn’t about secrets, it’s about shared understanding.
A great Event Storming session levels the playing field. If only one person understands the full process, the company has a problem. The goal is to get that knowledge out of Lisa’s head and onto the wall.
The Silent Observer
Finally, we have Tom. Tom sits in the corner, arms crossed, waiting for someone else to do the talking. Maybe he’s shy, maybe he thinks he has nothing to contribute. But when the session’s over, he’ll point out everything that was missed. Tom, we need you in the discussion, not just after it. If you know something, speak up. If you’re unsure, ask questions.
If you’re a Tom, force yourself to say at least one thing every 10 minutes. If you think something’s wrong, challenge it now, not after developers have already built the system.
What Happens After?
By the end, the wall should tell a story, a flow of events from start to finish. This map helps developers design systems that fit your world, not the other way around. The better you tell your story, the better the outcome.
Sometimes, gaps will appear. A step is missing. An exception hasn’t been accounted for. That’s good - it means the session is doing its job. Fixing these now is much cheaper than fixing them after development starts.
So next time you walk into an Event Storming session, don’t just sit back. Grab some sticky notes and start narrating. Your input is what makes it all work. And if you see a Greg, Lisa, or Tom in the room? Help them help the process. That’s how you get great software.