Estimating user stories: the 5 day challenge

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 (video at the bottom of this post). 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.The core of the 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 good literature out 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 :)

Here’s a video of the conference lightning talks – mine begins at 07:54…


12 thoughts on “Estimating user stories: the 5 day challenge

  1. This would fit very well with Tom Gilb’s EVO approach where he looks for the one thing that can be delivered next week that can make a difference.

  2. The one issue I’ve seen people have with your 5 day challenge is that they try and do it backwards, making stories bigger to fit into 5 days!

  3. The comment about Evo: yes I agree! I think the idea of this challenge is great, and I think it can be improved. You start from a “user story”. But a user story is just a means to an end; there is a business value that we want, actually we hope, to deliver with this user story. The real challenge is to start from what the customer really wants, and enumerate ways to deliver that. This is my Evo training speaking :)

    My second suggestion is that this is not just a challenge to the user story; it’s a challenge to our code base. 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.

    • @Matteo Yes, we’re moving towards starting with the problem instead of the solution with a couple of teams. Quite a shift in mindset for many people!

      And I definitely agree on the challenge to the codebase. Uninhabitable code is the next limiting factor to be tackled after we have a working pull system.

  4. Pingback: Evolving the kanban board | silk and spinach

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s