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.