Software Estimation Tips

These tips are taken from Software Estimation – Demystifying the Black Art by Steve McConnell, published in the Microsoft Best Practices series.  This book has proved to be an invaluable resource and I recommend it to anyone responsible for providing software estimates, be they developer, team lead or project manager.  The tips listed are not exhaustive and should be considered in their original context.

Critical Estimation Concepts

1. When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.
2. A target is a description of a desirable business objective; a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative but do not assume that it is the same.
3. Avoid using single point estimations, use ranges. Avoid using artificially narrow ranges so that you do not misrepresent the confidence in your estimates.
4. Never intentionally underestimate. The penalty for underestimation is more severe than the penalty for over estimation. Address concerns about over estimation through planning and control, not by bias.
5. Recognize a mismatch between a project’s business target and a project’s estimate for what it is: valuable risk information that the project might not be successful. Take corrective action as early as possible.
6. Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate cannot have more accuracy than is possible at your project’s current position within the Cone. Use predefined ranges in your estimates.

   

7. Include all necessary software development activities in your estimates, not just coding and testing. For example:
   i. Mentoring of new team members;
   ii. Deployment;
   iii. Requirements Clarification;
   iv. Technical Reviews;
   v. Performance Tuning;
   vi. Creation of Test Data.
8. On projects that last longer than a few weeks, always include allowances for overhead activities such as vacations, sick days, training days and meetings.
9. Never give an off-the-cuff estimate. Even a 15 minute estimate will be more accurate.
10. Always document assumptions embedded in an estimate.
11. Match the number of significant digits in your estimate (its precision) to your estimate’s accuracy. For example:
    i. “This Project will take 1 year” is not very precise but could be accurate.
    ii. “This Project will require 7,214 staff hours” is very precise but not accurate to the precision stated.
12. Don’t assume that effort scales up linearly as project size does. Effort and communication paths scale up exponentially.

Fundamental Estimation Techniques

1. Look for something you can count that is a meaningful measure of the scope of work in your environment.
2. Collect historical data that allows you to compute an estimate from a count. Our organization’s past performance is the best indicator of future performance, industry data is not reliable.
3. Collect a project’s historical data as soon as possible after the end of a project.
4. At all costs, avoid using expert judgement to tweak an estimate that has been derived through computation.
5. To create task level estimates, have the people who will actually do the work create the estimate.
6. Create both Best Case and Worst Case estimates to stimulate the thinking about the full range of possible outcomes.
7. Estimate new projects by comparing them to similar past projects, preferably decomposing the estimate into at least five pieces.
8. Use T-Shirt sizing to help non technical stakeholders rule features in or out whilst the project. The first table can be used to calculate Net Business Value.

   Development Cost
   Business Value	XL	L	M	S
   XL	0	4	6	7
   L	-4	0	2	3
   M	-6	-2	0	1
   S	-7	-3	-1	0

   Feature	Business Value	Development Cost	Net Business Value
   A	XL	M	6
   B	M	M	0
   C	M	S	1
   D	S	L	-3
   E	S	XL	-7

9. Have each team member estimate pieces of the project individually and then review estimates. Don’t just average estimates, arrive at a consensus that everybody is comfortable with.
10. Use an estimation software tool to sanity check estimates created by manual methods. Do not treat the output of the tool as divine revelation. For pointers to estimation tools, see www.construx.com/estimate
11. Focus on estimating size first. Then compute effort, schedule and cost from the size estimate.
12. Re-estimate at each milestone. Base new estimates on the project’s actual progress, not on the project’s planned progress.
13. Communicate your plan to re-estimate to project stakeholders in advance.

Estimation Scheduling Challenges

1. Do not shorten a schedule estimate without increasing the effort estimate.
   i. Larger teams require more coordination and management overhead.
   ii. Larger teams introduce more communication paths which introduce more chances to miscommunication which introduces more errors.
   iii. Shorter schedules require more work to be done in parallel. The more work that overlaps, the higher than chance that one piece of work will be based on another defective piece of work increasing the need for rework.
2. Reduce costs by lengthening the schedule and conducting the project with a smaller team.
3. Consider the project’s development approach in allocating schedule to different activities.