How to fight priority paralysis with Event Storming and DDD

3 minute read

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!

Drawing of a skeleton marking items on an DDD Event Storming design board. Event Storming is great to find the scope of your next target, you Walking Skeleton for example.

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:

Everyone went out very satisfied with these results.

The problem: What’s the next target

Woven wicker ball, that seems impossible to untangle. Finding where to start in a new product is a riddle of its own. Event Storming and DDD get collective intelligence to the rescue.

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:

Small dot stickers like you can find everywhere. Use them to negotiate and mark events and items that you want to see in your next target

  1. Hand them small dot stickers
  2. Ask them to mark what they want in the next target
  3. 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:

  1. Be specific and gather details. Event Storming should fill this first step.
  2. Identify both short term and long term goals. Here is the negotiation part.
  3. Start something on the list. As soon as you leave the Event Storming workshop, you should start something.

Drawing of an infographics of the Event Storming loop: Devs meet domain experts -> Grow collective intelligence superpowers -> Make complex decisions in a short time -> Try for real -> Learn -> Devs meet domain experts -> ... Getting started is the best cure against analysis paralysis

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!

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Leave a comment