Software Estimation

A practical approach

By Khang Nguyen

Heads Up

Accurate Estimation is a skill, not magic

  • Estimation in Software Development
  • Sources of estimation errors
  • Estimation practices

Estimation in Software Development

A misunderstood and neglected building block

Estimation is a building block,

with cumulative effects on other activities.

Estimation is a probability statement.

Estimation has a mis-understood goal.

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.

Overestimate or Underestimate?

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.

Sources of Estimation Errors

The failure to conceive software project as a big picture and eliminate variations

The name writing game

  • One developer, The rest are stakeholders
  • Developer knows how to write
  • Stakeholders know their names, but can't write
  • Business rule: no customer has to wait

The cone of uncertainty

Hard to get into shape

Organization structure

Bad orgnization structure is capable of killing both productivity and predictability

  • Makes room for multitasking to creep in
  • Employs incompetent technical skills
  • Apply incomplete/unskilled project management

Unstable requirements


Omitted activities

Examine Comedy & Pixatoo Estimates

Unfounded optimism


Other sources of error

Estimate Influences

Understanding of software project dynamics

Project size

reflects the amount of effort and variation

Type of software

Life-critical system is no e-commerce pal


The top 20% of the people produced about 50% of the output

Estimation Techniques

Count, Compute, Judge

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.

What can we count in a software project?

A few rules of thumb

  • Count something that closely reflects the project size
  • Count something that available early in a project
  • Count something consistent between projects
  • Count something statistically meaningful

Decomposition by Work Breakdown Structure

A checklist against forgotten tasks

Map omitted activities to

a Work Breakdown Structure

Justify Probability Statement

Single-point number is not a reliable.

But Best Case and Worst Case might also be not that good.

The problem with adding up best and worst cases.

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

The debut of "Most Likely 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

Estimate by Analogy

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

Proxy-based Estimation

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.

Where we can find proxy

  • Industry average data
  • Organization historical data
  • Project specific data

Popular Proxy-based approaches

  • Story Points
  • Fuzzy Logic
  • T-shirt Sizing
  • Standard Compoments

Collect Historical Data

Group Review

Environment for Wisdom of the Crowd

Criteria Description
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

Extreme Description
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"[5] 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.

Group Review Rules of Thumb

  • Have each team member estimate pieces of the project individually, and then meet to compare the estimates
  • Don't just average your estimates and accept that
  • Arrive at a consensus estimate that the whole group accepts

Estimation Procedures

Emphasizes counting and computing when possible, rather than using judgment

Calls for use of multiple estimation approaches and comparison of results

Communicates a plan to reestimate at predefined points in the project

Defines how the required estimation approach changes over the course of a project

Contains a clear description of an estimate's inaccuracy

Defines when an estimate can be used for each specific purpose

Calls for archiving estimation data and reviewing effectiveness of the procedure

Define a procedure