Therein lies the key to estimating!

It seems that too often we have a "gut feel" for how long a task should take, and we try to fit everything that needs to be done into that feeling. But if we first break the task down into definable pieces and then estimate each individual piece, the sum of the pieces will become a much more accurate estimate.

I've used the following example for years when discussing estimating. You are sitting in a meeting discussing some aspect of your software. A small change is needed, and you know right where that change is required. Someone asks, "How long will that change take?". "Ten minutes" you respond.

No, that change will take four hours.

Here are the various tasks involved:

1. Discuss and agree upon the change

2. Log into your system and locate and open the program

3. Locate the area in the program where the change needs to occur

4. Think through the change carefully to make sure there isn't other impact. May involve a quick look at other code.

5. Change the code

6. Test the code

7. Move the code into whatever change-management system you may have

8. The code may have to go through some sort of QA process, with internal analysts and/or customers.

9. Document the code change

10. Move code change into production

11. Final verification that the agreed-upon change is correctly working in production.

You could argue the application of some of the points above. The point is, in estimating we too often gloss over all the tasks required to support the primary task (#5 above), and thereby short our estimates right out of the gate.