Estimating user stories: the 5 day challenge
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
This is a quick note about an idea I’ve been using with a few software teams during the last couple of years. I also spoke about it briefly at the Scottish Ruby Conference this week. 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 story; fit the story to the size you want.
So there’s this big discussion going on about #NoEstimates and how estimating is wasteful, misleading etc. 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 is, at least for every team I’ve encountered, “how can we become more predictable in what we will 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.
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 find some core nugget of useful value within the story such that everyone agrees it could be delivered in five days or less, and such that it will be a useful and valuable product increment. Then deliver that core nugget to your users, and go and pick the next story.
This challenge process is fun, and it is exactly the kind of problem many developers and product owners are good at solving. Furthermore, there is goodliteratureout there to help you do it and get good at doing it. That’s a win.
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 three, or two, or one. I like 5 days because it almost always gives time to deliver an interesting chunk of value, and for many teams it’s an improvement over their current practice. 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.
Note that this 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 late, don’t try to squeeze the story into your estimate. It doesn’t matter if the story ends up taking 11 days or just two. The important thing is to do the story well, and then learn from the actual time it took.
In practice, this technique dovetails with the whole ecosystem of the other XP practices. And it fits best of all with a few other team micro-habits that I have evolved during the last couple of years. Hopefully I will be writing about some of these here soon. 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 :)