Always Multiply Your Estimates by π (2013)

For predicting the daily schedules on a film set I always "ran a simulation" of what would be done that day and just summed the predicted minutes. The simulation ran in my head of course, but it included things like: Actors drinking coffee and chatting, costumes getting ready, Camera department forgot memory card in the car, lunch breaks, someone arrives late, etc.

Obviously the major chunk were always scenes and they are usually also the major contributor to the insecurity of the prediction. E.g. working with people who you don't know, weather, technical problems (broken, missing stuff), stuff that just won't work (animals, certain scenes with actors).

But in the end what always mattered was that there was a time plan for each day and at the end of a day we would know wheter we are A) faster as predicted, B) on time or C) slower than predicted. The next day would then be restructured accordingly by the production and usually you'd be back on time by the end of that.

I was usually spot on with my predictions and we never had any issue with getting the planned stuff done.

With programming the whole thing is harder, because it can be even more unpredictable. But what definitly always helps is when you have a feeling for whether you are too slow, on time or you managed to build a time buffer for future doom.

Tom DeMarco talks about modelling-based estimates in Waltzing With Bears, mainly to break people out of the error they fall into of treating the soonest possible time something could be done as a realistic estimate of when something will actually be finished. There are also approaches like Function Point Analysis which provide an explicit model that you can calibrate your team against.

It's doable, but what people tend to forget is that it's work. If you want an estimate, I need to be able to expend effort providing it. It's an engineering activity that needs organisational support to do it at all well, but often you find an expectation that people will be able to pull an estimate out of a hat just having heard the faintest description of the problem, and there can often be a tacit belief (usually but not entirely from non-technical folks) that not being able to do so makes one incompetent.

This is where range-based estimations really shine. If you want an estimation right now, I will tell you on the spot that, "I'm 95 % certain it will be done no later than nine months from now, but probably sooner. However, I know it won't be done this week."

You want a narrower range than 0.25–9 months? You'll have to let me think about it. Maybe I can be just as certain that it will be done 1–5 months from now, if I get time to mentally run through the simulation, to borrow the terminology from upthread.

You want a narrower range than 1–5 months? I don't have the information I need to give you that. If you give me a couple of weeks to talk to the right people and start designing/implementing it, the next time we talk, maybe I have gotten the range down to 1–3 months.

I can always give you an honest range, but the more you let me work on it, the narrower it gets.

----

This is of course what's suggested in How To Measure Anything, Rapid Development, and any other text that treats estimation sensibly. An estimation has two components: location and uncertainty. You won't ever get around that, and by quoting a single number you're just setting yourself up for failure.