Task Estimation Patterns

Guess and feedback. "Hell, I don't know, maybe two weeks. ... Four weeks instead of two? Okay. I think this one will take three weeks." You will be surprised how fast this converges. Most folks forget the feedback part.
Estimate as a factor above or below a comparable task. "The option embedded bond was two weeks so this should be about half that."
Estimate in terms of ideal engineering time and multiply by an observed factor (2 seems to be good for greenfield development, 3 while you are in production).
Have experienced personnel do estimates. Pick projects the experienced personnel feel are similar in scope and complexity. Get the actual calendar time for each of these projects. Depending upon the level of risk the project can absorb, you can use the lowest, highest, or average value as your time and manpower estimate. Finally, estimate at the largest scale possible; do not estimate a bunch of tiny tasks and try to add them up.

Have experienced personnel do estimates. - How many years experience do they need to be considered "experienced"? Do they have to be experienced on the same kind of projects? Many people, especially programmers, claim to have 10 years of experience where in fact they only have one year, repeated ten times.

Pick projects the experienced personnel feel are similar in scope and complexity. - Very subjective. How similar does it have to be? What if there are only two? Only one? What if there aren't any?

Get the actual calendar time for each of these projects. - Don't level of staffing, load (other tasks/projects), holidays and vacations, and many other variables play into this at all?

Depending upon the level of risk the project can absorb, you can use the lowest, highest, or average value as your time and manpower estimate. - This makes it sound like gambling. If I want to minimize risk (that my estimate will be wrong), why not just pick the highest value (longer duration) software project ever?

Finally, estimate at the largest scale possible; do not estimate a bunch of tiny tasks and try to add them up. - Why not? Is there absolutely no value in "composite" estimation?

: Many project managers do exactly this - there are project planning tools designed to help them do it. Is this bad? Well, if you add up all the small tasks, it probably gives you a good minimum estimate. There will also of course be integration time, plus the time taken to design the interfaces between units etc. I see it as a valuable sanity check on higher level estimates.
: In my limited experience, estimation by composition of small tasks doesn't work because complexity of the whole project is often related to number of connection between tasks (or modules) rather than raw count of the tasks themselves. Like the number of diagonals in a polygon ((n^2 - 3n)/2), it goes up pretty fast. And if you have completely independent tasks, is it still one project? --DexenDeVries

Disagree: You will do a better job estimating if you can decompose the project into pieces small enough that you can reliably estimate each piece. The only way to do this is to keep historical as-built product size and resource usage data at a low enough level of granularity. Also keep original estimates around to calibrate with since estimates are all you have for not-yet-built products and you will have to navigate from the as-built historical data to your new estimate. It will take a few percent of total project cost to develop an estimate good to 30% if there is any innovation involved. 30% is small enough so as the project unfolds you can negotiate scope change and/or additional resources to meet responsibly made commitments. Making estimates at the largest scale possible is risky because it exposes you to the laws of small number statistics, and leads to optimistic estimates since it inevitably leaves out some aspects that are unique to the project at hand. In a nutshell, estimating with big pieces adds both variance and bias to your estimate compared with estimating with little pieces. DavidCary's note below describes his experience with an appropriate-scale process along these lines. --DaveVanBuren

It Gets Worse. The math itself produces wrong, seriously optimistic results even if your inputs are good (for arbitrary measures of "good").

"How long will it take?" doesn't have just one answer; it has a whole bunch of answers--each with its own probability of being right. The only meaningful answer is a cumulative probability distribution. Plot time to completion against the probability of meeting or beating that time.

We also know that deliveries are at best a bit early and at worst a lot late. The distribution is skewed, so the expected completion of a bunch of tasks is not the sum (or max if they're in parallel) of the individual expectations. You can do the calculation that way, but the probability of meeting or beating the estimate shrinks with each calculation, and the odds of success vanish.

The only way to get reliable estimates is to estimate and calculate with distributions (it's called MonteCarloSimulation?. See http://en.wikipedia.org/wiki/Monte_Carlo_method). Then you decide how much risk you can tolerate and plan accordingly. The same applies to cost estimates.

And the probability of being on time and on budget is smaller than the probability of either one alone.

--MarcThibault

And also, make sure you know what you estimate for. In a multi person project you will, at least initially, have a very diverse view among the developers of what it means to have finished a task. To deal with this, you should come up with a TaskCompleteDefinition.

I remember trying to estimate how long some programming tasks took, failing miserably, and then deciding that estimating programming time is inherently impossible. But "Painless Software Schedules" by Joel Spolsky 2000-03-29 "I've found that most programmers become very good schedulers with about one year of experience." http://www.joelonsoftware.com/articles/fog0000000245.html has just about convinced me that I can learn to make adequate estimates; it's not even that difficult. Just a few minutes a day, updating a simple spreadsheet that, as a bonus, also helps TimeManagement. -- DavidCary

See: GopherHoles, StoryEstimate, IdealEstimates, LoadFactorInEstimatingOtherProjects

Contrast: NegotiateEstimates, GuessTheNumber, GiveMeEstimatesNow, EstimationWoes, SchedulingMyths, EstimationRuleNumberOne

CategoryProjectManagement, CategoryPattern, CategoryAntiPattern (can this page be both pattern and anti-pattern?)