Estimating user stories

The 5-day challenge

This is an article I wrote in 2014, rewritten slightly to account for the ravages of time and to incorporate the comments I’ve received since then. It’s about an idea I've introduced to every software team I’ve coached during the last eight years. If you try it, please publish your experiences and link to them via the comments here.

TL;DR:
Don't guess the size of a user story;
slice the story until it’s the size you want.

So there's this big discussion going on about #NoEstimates — and how estimating is wasteful, misleading etc — for what seems like forever. But there are very few published practical alternatives. So what to do if you want to do less estimating? Honestly, I think that's the wrong question to be asking. A more important question, at least for every team I've encountered, is "how can we become more predictable in what we will promise and deliver?" Estimates only go so far in answering this question because, well, they're just guesses. It doesn't matter whether they are expressed as hours, pair-hours, story points, complexity points, Gummi bears or whatever; someone somewhere will attempt to do arithmetic with your estimates and thus turn them into "facts". So estimating is hard, and it's guesswork; it is not my intention here to grumble on about all the side-effects of that — you can read all of that stuff elsewhere. Instead, let's cut to the chase and do something about it.

Estimates are risky and difficult. So let's try the opposite. Instead of estimating the next story, let's play to our strengths as developers and give ourselves a technical and analytical puzzle: Let's fit the story to the estimate. Here's how it works…

When the team picks up the next story, apply the "five-day challenge". First ask, "can we deliver this in 5 days?" If the answer is "yes", just do it and then pick up the next story. But if the answer is "no", have the whole team identify some core nugget of useful value within the story such that everyone agrees:

1. it could be delivered in five days or less, and

2. it will be a useful and valuable product increment.

Deliver that core nugget to your users, then go and pick the next story.

(Historical note: This challenge is very similar to the approach used by Tom Gilb in his EVO method, in which the team is asked to look for the one thing that can be delivered next week that can make a difference.)

This challenge process is fun, and it is exactly the kind of problem many developers and product owners are good at solving. That's a win. Furthermore, there is plenty of good literature out there to help you do it and get good at doing it. Here are three great articles that can help with that:

1. Three Steps to a Useful Minimal Feature by Joe Rainsberger

2. How You’ll Probably Learn to Split Features, also by Joe Rainsberger

3. Guide to Splitting User Stories by Humanizing Work

Shortly after you have split the story to fit into five days, the Product Owner should take each of the edge cases you peeled off, turn them into stories and push them back down the queue. One or two of them may be the next stories to be scheduled, while others may wind up never being picked. All that matters right now is that they aren't essential to delivering the current story, and thus need occupy no more developer time this week.

Of course, if your stories are already small, instead of 5 days pick 3, or 2, or 1. I like 5 days as a starting point because for many teams it's an improvement over their current practice, and it almost always gives time to deliver an interesting chunk of value. The important thing is to pick a number of days and stick to it until you are confident that you have that size of story nailed. Then try reducing it by one day and learn how to slice your stories even more thinly.

When you have delivered the story, record the actual number of days it took. If that differs from five days, take 5 minutes as a team and list the reasons for that variance. Use this to help you do a better job of fitting the next story to 5 days (or less). You’re aiming for stable and predictable first, then for gradually smaller timeboxes.

Note that the 5-day challenge is NOT a challenge to the team, it's a challenge to the story. You all sat down together and dug out a core nugget of useful value, so now go ahead and deliver that without taking any short cuts. If you find yourselves running later than 5 days, don't try to squeeze the story into your estimate. It doesn't matter if the story ends up taking 11 days or just 2. The important thing is to do the story well, and then learn from the actual time it took.

Why have I posted this article in a series about Habitable Code? Because the habitability or otherwise of our code represents the biggest hurdle to slicing our stories thinner and thinner. Back in 2014 Matteo Vaccari wrote this comment on my original blog post:

This is not just a challenge to the user story; it's a challenge to our codebase. Why does it take 5 days to implement this request? Shouldn't we be able to implement this by a reconfiguration of our existing objects? Why is our codebase not closed with respect to this kind of variation? This is a challenge to our process and to the way we program.

I made a similar point in Don’t Forget the Developers: ultimately the habitability of our code is what will determine whether our “agile adoption” has any chance of succeeding.

In practice, this technique dovetails very well with the whole ecosystem of the eXtreme Programming (XP) practices. And it fits best of all with the other team micro-habits that I have evolved through my coaching practice over the last ten years or so. I may write about some of those here too. Or you could hire me to help your team implement XP, and find the best fit for the XP principles and practices in your organisation 🙂.

Here's a video of me explaining the 5-day challenge in a lightning talk at the Scottish Ruby Conference in 2014 (you need to skip forward to 07:54 because Substack doesn’t allow me to set the start time):

Things to try:

Next time you have to estimate a user story, try the 5-day challenge instead. (If your stories already typically take less than 5 days, try the challenge but with a smaller timebox.) Let us know in the comments what happened, what your team and Product Owner learned, and how you plan to take this idea forwards.

And when you get really good and this, and your team can reliably and predictably deliver value every day, try forgetting about user stories and slice the customer’s problem instead?