Fibonacci Dev Estimate

Say you have a programming task. In a planning meeting you estimate that this task will take a day to complete. Unfortunately, the task proves to be harder than you anticipated, so at the end of a day you’re not done. The next planning meeting comes around and you have to give a revised estimate. You say that it’ll take another day because–well–it really does seem like it’ll take another day. You have a better grasp on the task now, so it appears easier. Besides, you’ve already made a day’s worth of progress on it. But then another day goes by and you’re still not done. What do you give as a further revised development estimate in your next planning meeting?

Here’s what you don’t say: it’ll take one more day.

Maybe that seems obvious reading it here, but in practice it’s a difficult thing to do. Everybody in the room wants you to tell them it’ll take just one more day, and you want to tell what they want to hear because you’ve already disappointed them twice. Plus it’s likely your original estimate created unrealistic expectations, and unless you re-level-set, people (including possibly yourself) may continue to labor under the misapprehension that this is a one day task.

Here’s what you should say: it’ll take two more days.

If you hit that two day schedule, great. If you don’t, your next estimate should be three days. Then five. Then eight. Go marching right on up the Fibonacci series. Thirteen days. Then twenty-one. Then…well, hopefully your organization is sufficiently agile (or Agile) to be able to accommodate projects that turn out to be orders of magnitude more difficult than they appeared at first glance because that sort of thing happens. But even then you need some visible indication of when it is happening, and a ballooning dev estimate fits the bill. In any event it gets people’s attention.

There’s nothing magic about the Fibonacci series here. It’s just convenient–something that grows fast, but not too fast, is odd enough to be memorable, and arbitrary enough to remind you that these estimates are never better than wild guesses anyway. The most important thing is that with each missed deadline your estimate increase. There’s a good reason for this: you’re not an idiot. The fact that you made and missed an estimate is telling you something about the difficulty of the problem. It’s signal, not noise, so use it.

This entry was posted in Those that have just broken the flower vase. Bookmark the permalink.

5 Responses to Fibonacci Dev Estimate

  1. I’ve just had an opportunity to share this with my dev pod at work — one of us was kvetching about the “one, two, or three” point estimate system used by Pivotal Tracker’s defaults.

    I was pleased to advocate for the “one, two, three, five, eight” Fibonacci series estimator and point here. Nice explanation!

  2. W.P. McNeill says:

    Credit where credit is due: my former co-worker John Whitley came up with the idea of using Fibonacci numbers as units of estimated development effort in Sprint planning meetings. His idea was to call attention to the arbitrariness of these estimates. (I have a vague undergraduate memories of Roland Barthes calling signs “honest” when they drew attention to their own artificiality. Same idea.) My interest here is focused on reestimation, particularly in stressful situations.

    • I recognize the distinction between Fib as dev estimate and Fib as re-estimate. Your point applies, I think, to the *non*-arbitrariness of the F series for re-estimation. It says, I think, “your next estimate should be equivalent to your last two blown estimates — together”.

      I think prospective estimates are often just a process of mentally running through the future of blowing an estimate a few times — they’re not so different from re-estimation, are they?

      • W.P. McNeill says:

        The Fibonacci values are non-arbitrary inasmuch as they are at first slowly then rapidly increasing. For any level of quantitative accuracy beyond that, I believe the values are arbitrary. (Though wouldn’t it be interesting if you measured schedule slip times and found that they actually did proceed as a Fibonacci sequence?)

        In the way I’m thinking about it, prospective estimates are different from reestimates because when making the latter you have access to an additional piece of information—the fact that you missed a deadline—which informs your thinking.

      • W.P. McNeill says:

        Or maybe I’m just misunderstanding what you mean by “prospective estimates”…

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