Wednesday, December 17, 2008

Introduction to Project Estimation

At Devoxx08, Giovanni Asproni gave a talk on Project Estimation. He emphasized the need to distinguish estimate from targets and commitments. Estimates are approximate estimation of the value, number or quantity of something (2 to 4 days, 10 to 20 million). A target is a desirable business objective (Support x users, do not exceed 1 million dollars). Commitment is a promise to deliver functionality with a certain quality by a certain date (search functionality will be available in next release). These three are independent of each other, but you should set targets and commitments based on your estimates. The estimates are not negotiable. But the targets and commitments are. The estimates are used to determine if the targets and commitments are realistic. Usual estimates include size, effort, time, cost, risk. Given some constraints (time and cost), estimate the other.

Estimates should be accurate and not precise. This means use the correct measurement unit. If something will take years, do not estimate in days or hours. Hours will be more precise, but it will be less accurate than a more appropriate measurement unit like years.

The cone of uncertainty shows that your estimates are off by a margin of error at the beginning and gets more and more accurate as the project moves along. The cone is the same for sequential or iterative projects. Do not commit at the beginning of the cone, but at a later date after several iterations or at the product design specification.

People who do the work should create the estimates. All assumptions should be taken into account. All tasks should be included. Make sure to plan for leave/absence and side tasks such as phone, email, meeting, browsing.

There are several techniques for estimation:

1) Count, compute, judge: count if you can, compute if you can’t, judge as a last resort.

2) Mathematical (COCOMO): Tools available but based on “knobs” (inputs unknown/inaccurate).

3) Historical: Industry, company or project data. Can be accurate, avoids wishful thinking.

4) Analogy: Compare to similar projects, simple to implements but subjective and less accurate.

5) Proxy: Use proxy to effort like story points or t-shirt size. Can be highly accurate but require experience.

6) Decompose and recompose: Split into small chunks and aggregate. Can be accurate but be careful because sum of individual chucks will not equal whole.

7) Expert Judgment: Individual or group (Delphi, planning poker). Can be highly accurate, but need experts.

More than one can be used at the same time as a sanity check. Start with historical data if available. If not use, expert judgment, proxy, or analogy. Keep track of your data and use it to improve as you go along. Estimation is an ongoing activity. Refine the estimates as you go along and remember that estimates will always be wrong!

This presentation is available on Parleys at