Best software estimation recommendations

I have collected the best of Steve McConnell’s Software Estimation: Demystifying the Black Art tips. If you haven’t read it already, I think it is a must for Software Engineers.

“Distinguish between estimates, targets, and commitments.” I believe this is the best recommendation of the book. Estimates refers to a projection of how long is going to take; target dates are set based on business drivers and could be achievable or not; commitments is a promise to deliver a functionality or a system.

“When you see a single-point estimate, that number’s probability is not 100%. Ask what the probability of that number is.” Any estimation should be associated with a likelihood of achievement such as 60% chance of getting it in 3 months, 80% change in 3 and a half months.

“Don’t intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.”

“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.” Accuracy on your estimate increase as you get closer to complete software development, having great uncertainty at the beginning. Have a look to the Cone of uncertainty.

“Don’t expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can’t accurately estimate an out-of-control process.” First improve your development process, then your estimate practices.

“Include all necessary software-development activities in your estimates, not just coding and testing.” It could happen to developers that only the Development activities are included, you should include business analysis, testing, management overhead, architecture and user interface design.

“In collecting historical data to use for estimation, start small, be sure you understand what you’re collecting, and collect the data consistently. Collect a project’s historical data as soon as possible after the end of the project.” After having to estimate many projects with no historical data to compare and use analogy-based estimation, I believe this deserves an article on itself.

Achieve better estimates by capturing better actuals (Pablo’s recommendation)

“Use an estimation checklist to improve your individual estimates. Develop and maintain your own personal checklist to improve your estimation accuracy.”

Use group reviews to improve estimation accuracy.” Team work.

Use multiple estimation techniques, and look for convergence or spread among the results.” Validate yourself.

Do not shorten a schedule estimate without increasing the effort estimate.” This is a great advice. The classic joke 9 women can’t deliver a baby in 1 month applies. It is tempting to add more developers, testers or analysts to shorten the schedule, however larger teams require more coordination and management. In some cases, parallelizing many tasks it is not even possible. So, review estimates after changing the schedule estimate.

Reduce costs by lengthening the schedule and conducting the project with a smaller team.” The opposite to the previous tip also applies. By stretching the schedule we could achieve some savings due to smaller teams and efficient communication.

Document and communicate the assumptions embedded in your estimate.” You will get less questions and achieve more understanding from your audience. There is nothing more interesting than 6 months after you provided an estimate someone comes along and ask you how did you get there.

Understand that executives are assertive by nature and by job description, and plan your estimation discussions accordingly.” Have in mind the outcome of the meeting before getting into the meeting room.

“You can negotiate the commitment, but don’t negotiate the estimate.”

Generate as many planning options as you can to support your organization’s goals.” The idea is to resolve the problem together (meaning business plus IT), not to win a negotiation. So, attack the problem, not people.

This is my second article around software estimation, you could find the first one: Which software development estimation technique work better depending on the project phase?