Six guidelines for Software Estimates

Estimating is often a big weakness for software developers. Here are some basic guidelines.

1. No spec = no estimate

If you haven't been given a decent spec, don't give an estimate!

2. It takes about 25% of the overall project to do a good estimate.

This is a rule of thumb for how much effort you should put into an estimate, even though you don't know how big the project will be until AFTER you've done the estimate.

3. Over-estimate rather than under-estimate

The problems arising from over-estimating are much smaller than the problems from under-estimating.

4. The biggest problem is going to be the issues you haven't even identified yet.

But doing a spike will help identify SOME of those issues.

5. Guideline - Four things functional specs must have

1. Business problem overview
2. Use Case story
3. Test scripts for testers. (This is different to TDD.)
4. Sign off by the customer

Other things you might need to know

• Data flow
• Data mappings
• Data manipulation
• Exceptions to the business cases / data-flow
• Who maintains state, and where state is kept

6. Things the developer must do

1. High level design
2. Technical specification.
3. A Spike
4. Compare the size of the task with previous tasks.
5. Initial estimate - only after doing the first 4 points are you ready to do a valid initial estimate.
6. Review the estimate with your supervisor BEFORE beginning the project. Just doing a walk-through with someone else can help.
7. Subsequent estimates / burn-down chart.
8. Keep track record of actuals versus estimates, so you can do better estimates in the future.
9. Retrospective review after the project.