By Khang Nguyen
Accurate Estimation is a skill, not magic
A misunderstood and neglected building block
with cumulative effects on other activities.
A good estimate is an estimate that provides clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit targets.
The focus of the estimate should be on accuracy, not conservatism. Once you move the focus away from accuracy, bias can creep in from different sources and the value of the estimate will be reduced.
The failure to conceive software project as a big picture and eliminate variations
Bad orgnization structure is capable of killing both productivity and predictability
Understanding of software project dynamics
reflects the amount of effort and variation
Life-critical system is no e-commerce pal
The top 20% of the people produced about 50% of the output
Judgement alone is the most inaccurate form of estimation.
Counting and computing are proven to be more reliable.
You should always count related things first, then compute what you can't count and finalize the estimation with calibration data. Only use judgement as the last resort.
A checklist against forgotten tasks
Single-point number is not a reliable.
But Best Case and Worst Case might also be not that good.
If each of the individual Best Case estimates is 25% likely. Then the chance of deliver two features with Best Case estimates is 25% of 25%.
Same thing with adding up worst cases
Expected Case = [Best Case + (4 x Most Likely Case) + Worst Case] / 6
Or if optimism happens in a consistent pattern
Expected Case = [Best Case + (3 x Most Likely Case) + (2 x Worst Case)] / 6
|Break similar previous project into pieces using requirements and WBS||Count|
|Compare the size of new project and the old one piece by piece||Judge|
|Build up the estimate for the new project's size as a percentage of the old project's size||Compute|
|Create an effort estimate based on the size of the new project compared to the size of the previous project||Compute|
|Calibrate the result||Judge|
Find another metric that is correlated to what we want to estimate ultimately. Once the proxy is found, we estimate or count the number of proxy items and then use a calculation based on historical data to convert from the proxy count to the estimate we really want.
Environment for Wisdom of the Crowd
|Diversity in opinion||Each person should have private information even if it's just an eccentric interpretation of the known facts.|
|Independence||People's opinions aren't determined by the opinions of those around them.|
|Decentralization||People are able to specialize and draw on local knowledge.|
|Aggregation||Some mechanism exists for turning private judgments into a collective decision.|
Enviroment against Wisdom of the Crowd
|Homogeneity||The need for diversity within a crowd to ensure enough variance in approach, thought process, and private information is stressed|
|Centralization||The hierarchical management bureaucracy limits the advantage of the wisdom of low-level engineers.|
|Division||Information held by one subdivision was not accessible by another.|
|Imitation||Where choices are visible and made in sequence, an "information cascade" can form in which only the first few decision makers gain.|
|Emotionality||Emotional factors, such as a feeling of belonging, can lead to peer pressure, herd instinct, and in extreme cases collective hysteria.|