Poll of techniques used by SO developers to estimate the effort or time for a project or task

Question

There has been quite a bit of discussion about how to apply specific estimation techniques, or which estimation method is better than others. But it's hard to get a sense of which estimation practices people actually use.

What I am interested in is an informal poll of what types of estimation techniques people typically use.

Please add or upvote those techniques that you find you commonly use when estimating projects or work - the idea is that the most popular techniques would float to the top. Please look over the techniques listed before adding your own.

Please don't downvote techniques that you don't like or don't practice - the idea here is to get a sense of which techniques are popular or commonly used by people.

If you have opinions about specific techniques or thoughts about how you apply them, please add them to the comments for an item.

Answer 1

I don't estimate - I just start developing.

Answer 2

I use function point analysis.

Answer 3

I ballpark the numbers on gut feeling.

Answer 4

I look at my historic work and look for actual effort from similar activities.

Answer 5

I use COCOMO (COnstructive COst MOdeling) as an estimation technique.

Answer 6

I use peer-review estimation - where a group reviews and provides input on all estimates.

Answer 7

I use historical precedent with difficulty modifiers:

Time added per screen being developed (in a GUI).

Time added for algorithmic complexity (want sorting on a page which invariably leads to desires to allow user to modify sort).

Time added for any inter-screen dependancies/modifications.

Time added for any server communication.

Time added if I'm not wholly in charge of defining communication protocol to server.

Time added if the API to call the server does not exist yet.

Time added for any local persistance (caching data located on a page).

Some default overhead for communication, this depends of how clearly a client/business group can explain needs.

Some overhead for project management issues (SCM, occasional refactoring, buildout of helper classes related to project).

All of these factors cannot be quantized to a single number. They depend heavily on the developer doing the work, and the people in charge of deciding what is an acceptable end result. The more people involved in that, the greater the time. The less experience you have in some aspect of development, the greater the time. The complexity of user interactions going up can exponentially increase the time required to properly define what should happen, much less develop the end solution.

If you're doing it right, every answer for each part should end up being roughly one to four days. Anything longer and you should have broken it out more, and nothing new ever really takes under a day - only bug fixes.

Answer 8

Gut-feeling from experience is workable to guess how long a SMALL task will take.

For anything of serious scale, FogBugz EBS is awe-inspiringly useful.

If you've never used it for a project, I strongly suggest you get a free FB-on-demand account and give it a go.