Cynefin and Story Splitting

Cynefin as of June 2014 - From Dave Snowden, released under CC BY 3.0
Cynefin as of June 2014 – From Dave Snowden, released under CC BY 3.0

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.

Update, October 2020: Richard’s latest story splitting resources are available at Humanizing Work.

Related Articles


Your email address will not be published. Required fields are marked *

  1. I disagree about the value of stories in the Complex Domain. Although not rigid the Complex Domain is more the territory of unknown unknowns where you benefit from running multiple simultaneous, non-complimentary experiments within a bounded context in order to acquire knowledge you previously didn’t have.

  2. Hi Richard,
    thank you for making this connection! As you pointed out, the interesting difference occurs in the complex domain, where you build to learn. Interestingly this idea also exists in the LeSS community. Craig Larman calls this approach: “take a bite” and mentions it in the Introduction to LeSS chapter in the upcoming book (see page).
    I’m happy to see how all of this fits together nicely 😎

  3. Hi Richard,
    Thanks a lot for sharing this. I find it so important to be reminded of how to behave best in a complex domain. So often see many people — and often including myself — falling back to the natural reflect “to plan better”. Therefore we all need to understand better in which domain we are in and how to address it.
    For me personally the next important question is: what is the origin of the complexity, is it intrisic in the problem domain or how much did we added on top, e.g. by using complex team structures, legacy code, etc.? Maybe we have a chance to reduce the complexity?