How to fight priority paralysis with Event Storming and DDD
Where should we start? It’s easy to fall into priority paralysis as you envision an ambitious product. Let’s use DDD Event Storming to scope your next step!
I’ve said it earlier: Event Storming helps you to make complex decisions in a short time!
Story of a new feature
A few months ago, at work, I trained some people to run Event Storming workshops. Some of them tried their new knowledge on a significant feature involving many teams.
They had been wondering how to start this topic for weeks when they ran the Event Storming.
Two of the outputs of these 8 hours of Event Storming were:
- They agreed on an end-to-end Walking-Skeleton to test and build first
- They had a first idea of the end to end NFRs (Non-Functional Requirements) that the business needed
Everyone went out very satisfied with these results.
The problem: What’s the next target
When you don’t all agree on the next target, it is very difficult to be effective.
- Prioritization is tricky
- Progress is slow as there is not enough focus
- You won’t reach a sustainable pace. Running after too many rabbits generates stress.
It gets even worse with different stakeholders who have different topics in mind.
- Domain experts care about features or business risks
- Technical people have NFR and maintainability risks in mind.
Getting all these people to agree on the next step is a real challenge!
An easy ES trick!
Again, the shared understanding generated from Event Storming makes this step simple. Here is what you can do to get people to agree on the next target:
- Hand them small dot stickers
- Ask them to mark what they want in the next target
- Let them negotiate
The result is a mix of features and de-risking. Stickers work great because they are easy to remove. From my experience, this scoping step takes about 30 minutes.
The key to making this simple activity work is to have enough shared understanding. You’ll build this with the beginning of the Big-Picture Event Storming. Go at least as far as the storytelling. It works even better if you identified the contexts and subdomains.
The more shared understanding you built, the easier the negotiation is.
Why does it work?
Shared understanding is the first enabler. Here are other aspects.
By working together in the Event Storming, people get to know and trust each other more. As a result, it also improves collaboration after the workshop!
Best practices against priority paralysis provide another explanation. DB Hurley presents a 3 steps process in First Things First: How to Handle Priority Paralysis:
- Be specific and gather details. Event Storming should fill this first step.
- Identify both short term and long term goals. Here is the negotiation part.
- Start something on the list. As soon as you leave the Event Storming workshop, you should start something.
Where’s the catch?
OK… there’s an implicit assumption here. I did not mention system design constraints here.
How can we address critical features and risks first? Without bothering about the code?
To do this, you’ll have to code by refactoring and change the code many times. You’ll need to master incremental development techniques. Without them, you’d have to build full components in large work batches.
If you want to learn ‘code by refactoring’ techniques, the simplest way is to start a coding dojo.
Don’t let priority paralysis kill your product before you even start!
Watch out for projects or products that are taking too long to start. If you hear something like:
We just need to figure out how to cut the elephant…
Suggest an Event Storming!
In 2 days of effective collaboration, you’ll agree on the next target. As a bonus, you’ll get all the other outcomes of ES:
- Shared understanding
- Growing tech-domain collaboration
- The beginning of a ubiquitous language
- High impact quick fixes
- …
Running and Event Storming is not rocket science. If you are wondering how to start, follow the guide!
Leave a comment