I use my sorted list of story criteria when I have to back off getting the perfect story. We went into this yesterday here, and for the threading impaired, the blog will be up late tomorrow.
There are a bunch of criteria for the perfect story, so many that at times I’m at a loss to find any story that meets them all. When I have to have a story, and I can’t get a perfect one, I have to back off and let one or more criteria slip.
The criteria, listed in the order I let them slip:
- Plannability
- User-Value
- Size
- Verticality
- Shippability
Let me say that in a different way.
If I can’t get all five, the first one I let slide is plannability. If I can’t get perfection in the remaining four, the next thing I let slip is user-value. Most commonly, with those two set aside, I find something that will do nicely. I very rarely have to slip the others.
Plannability, you’ll recall, is itself a short list of criteria: independence, negotiability, unity. Why, at story-for-coding time, am I willing to let go of these?
Simple, really: because it’s story-for-coding time, not story-for-planning time. Stories are used in two different activities, and those two occur at different times. The planning time happens before the coding time. The importance of plannability is high, then. But not now. In pure pull arrangements — I prefer and advocate for them — the importance of plannability is actually very low to begin with. Plans in such systems are usually just sketches of direction. They’re essentially a strong value-definer’s private notebook of "what’s next?" notes.
(Advocacy, then I’ll let it go: I’ve never seen a corporate planning session work for any ends other than supporting a) infighting and b) 19th century managerial models. They seem to me to be almost universally pure waste executed in the name of powerpoint-based theory.)
Most of the rest of what I’m going to say is about slipping the User-Value criterion. I’m going to skip that for a second and polish off the rest of the list, then we’ll come back to that one.
Size, verticality, and shippability are criteria I have to let slide very rarely. When I do, I let them slide in that order. As my friend Tom Johnson pointed out yesterday, this means I never slip shippability. If I have to slip all the criteria, I don’t have a story. I have a time machine that’s taken me back to the ’80s, and a fat notebook of "requirements". I’ve lost all the value stories bring.
Size and verticality are very close in priority. The truth is, if I get this close, I sometimes choose one to preserve and sometimes the other. As I say, usually I don’t have to choose at all, because user-value has already slipped. Size is super-important, for reasons we spoke of yesterday. Large estimates are non-linearly less predictive than small ones. Estimated one day can become 1.5. One week can become 3 weeks. One month can become four, five or six months. One quarter, well, it is to laugh.
Verticality is also super-important. Recall, verticality means that whatever I’m calling a story, it touches all the horizontal layers in the system. The pithy way to say it: "From pixels to bits to pixels". Why do we put such a high priority on verticality? The deep reasoning is kind of complicated, and will spill out when we go back to user-value. There’s a simple way to understand it, though, without the deep reasons. It creates more actual progress for the outsiders.
Imagine you’ve got 10 features to do in a fixed time. Estimates & brushfires being what they are, you only get half the work done. Would you rather have 10 features 50% done or 5 features 100% done?
Spoiler: Ask the nearest user if you can’t figure this out yourself. 🙂
It’s fascinating to me to watch this in the field. One constantly sees 10 people doing 10 stories for 10 days and getting zero of the stories done. Then they go have a sprint review and hang their heads. The beatings will continue until morale improves. Rinse, lather, repeat.
Okay, time to address user-value. I’ll give you fair warning: what I’m going to say here goes against a great deal of received "Agile". It undermines a variety of rules, slogans, and pitches. There may be fireworks as a result. Most failures to split seem to derive from the belief that every valid story must have as its boundary a completely satisfied user, or in most modern shops, some (sadly) external customer proxy.
That is, the user-value criterion is viewed as universally the most important. Every perfect story does meet the user-value criterion. But it isn’t the most important criterion. I think of it this way: it doesn’t matter whether the finished story satisfies the user if we can’t structure the work so that we finish the story.
- We can’t finish the story if we can’t ship it.
- We can’t finish the story if it isn’t pixels-to-bits.
- We can’t finish the story if it’s too big to get our heads around.
A story I can’t finish is a story that provides zero user-value. It just stays out there on the wish list forever, or until the day your user finds some other way to get it done, usually from another supplier. Some folks will start telling us that "engineering stories" are bad. Or they’ll soften it, and tell us "those are tasks". Let’s address those two.
"Those aren’t stories, those are tasks.": This is intellectual purity creating confusion in the name of clarity. What they are is vertical sized shippable chunks of work. They are valuable because they meet those three criteria, and we need those criteria to do them at all.
Some will now wrangle about how to represent that in jira. You really don’t want to get me started here about all the damage done by jira and its competitors. Suffice to say, jira works for me, i don’t work for jira.
"Engineering stories are bad." Now, here, I want to be a little more kindly. If you’ve been out in the world at all, you’ve seen engineering stories do bad things. But I’m going to offer a re-framing: I would suggest horizontal stories are bad. That is, most of the woe coming from engineering stories is coming from dividing the work horizontally.
- First story: make all the database changes.
- Second story: make all the service changes.
- Third story: make all the front-end changes.
This is a recipe for failure.
But that won’t happen if we hold onto the criteria in the order I’ve offered, because we’re still holding on to our verticality criterion, even as we let user-value slip a little.
The final reason to cling to user-value is that it, well, it feeds the admiral’s cat. We make money by changing software to please users. Every step we take away from that is a risky one. Here’s the thing about that complaint: it’s entirely legit.
Remember context, here. We don’t start with stories that don’t fit all the criteria. We’re not trying to go gentle in to that good night. If we were, that would be a Very Bad Thing[tm]. We’re relaxing criteria in order of importance so we can do the work. Pragmatism, yo.
Alrighty, then. Let’s wrap this up. Sometimes I have to step back from the perfect story. I step back in certain ways before I do it in others. I relax user-value before I relax verticality, size, or shippability. I have to do this, because if I don’t, a variety of different problems tend to slow or even halt my making. And that’s a thing we can’t do as professional developers.
I’m done for now. I’ll be back in a couple of days. The continuation of the series: actual casebook stories. Places where my teams have split stories in clever ways using these criteria in this order and still delivered.
I’m headed up to DC today, gonna see Cirque du Soleil with the family and stay overnight. I’m a little tired and crabby, but also excited to see it and pleased to spend time with some of my favorites.
I hope you’ve got a little excitement in your Tuesday. Have a good time!