Name: Precision Estimation
Developers continually get asked to provide an estimate with a high degree of accuracy. They are expected to spend a fixed period of time to produce the estimate.
Project managers like estimates. Estimates allow people to plan, and planning is good. “Gold Donors” like estimates because it lets them have an idea of how much they are going to have to pay.
This isn’t bad. The problem is that estimates have a certain level of confidence, and that confidence can be expressed in several ways. The most common is a fixed window: e.g. feature X will cost $100,000 +/ 10%. This is a typical format for things that have a highly predictable cost.
There is, however, a second aspect to this estimate. This aspect is how confident you are that it will fit inside this window. By implication, you are 100% confident that it will fit in this window. So you will be equally surprised if feature X costs $110,001 as if it costs $200,000… both values are outside of your “window of confidence”.
This brings up the question of precision vs. accuracy. Precision is related to how tight your window is. Saying that feature X will cost $100,000 +/- 10% is a precise</eM estimate. If feature X costs $109,999, then the estimate is accurate. If it costs $110,001, then the estimate is inaccurate.
Needless to say, increasing the precision of an estimate will lower the accuracy. To increase accuracy, you need to do research: you need to actually prove things. For highly predictable and repeatable tasks, then you have little research to do. If I'm building a house, of a set plan, then the only research that has to be done is to check the soil conditions to see what kind of foundation I need. After that, I can have a highly accurate and precise estimate.
Research takes time. The amount of time it takes relates to the novelty and complexity of the task.
When you estimate, you typically break a task down into several chunks. These chunks themselves will be easy to estimate. Then you add them up and say you're done. But this effects precision and accuracy.
Given a fixed quantity of time, you can end up with an accurate estimate or a precise estimate. The accurate one will be wide. The precise one will be narrow. They will probably both be useless. 🙂
Express estimates with _both_ accuracy and precision confidence. Rather than saying that feature X will cost $100,000 +/- 10%, say you have 90% confidence that it will. Give some hints as to whether it is likely to be over or under if you’re wrong.
Focus on breaking estimates down into small tasks. Develop these tasks incrementally. As the the tasks get built, adjust the remaining estimate. Compare the accuracy of the estimate with the actual value. Learn!
If you can not give an estimate that is confident, don’t. If the business doesn’t like that, explain that you need more time. Ideally, invest that time by developing the sub-tasks in an incremental fashion.
Pay attention to your “confidence” estimate. If you regularly say you have a 50% confidence in an estimate, then you should be wrong about half the time. If you are only wrong a third of the time, then something is wrong.