As I was preparing for my Agile Denver session on Unscaling, which leaned heavily on the Cynefin Framework, I reread Liz Keogh’s excellent post, “Cynefin for Devs.” I realized that I use my story splitting patterns in a few different ways depending on the domain, and I’ve never been explicit about this (which probably confuses people I’m coaching).
Unless you’re already familiar with Cynefin, go read Liz’s post. I’ll wait.
Here’s how story splitting looks different for each Cynefin domain:
Simple/Obvious – Just build it. Or, if it’s too big, find all the stories, and do the most valuable ones first.
Complicated – Find all the stories, and do the most valuable and/or most risky ones first.
Complex – Don’t try to find all the stories. Find one or two that will provide some value and teach you something about the problem and solution, build those and use what you learn to find the rest.
Chaotic – Put out the fire; splitting stories probably isn’t important right now.
Disordered – Figure out which domain you’re in before splitting so you don’t take the wrong approach.
The most important nuance is in the complex domain, where starting the work will teach you about the work. In this situation, it doesn’t make sense to try to find all the small stories that add up to the original, big one. Instead, it’s more productive to find one or two you can start right away in order to learn.
Some are uncomfortable with this approach, wanting all the stories enumerated and sized to be able to project time over the backlog. But if you’re really in the complex domain, this only gives you the illusion of predictability—the actual stories are likely to change as you get into the work. Better to be transparent about the uncertainty inherent in complex work.