Seven tips for getting better software estimates

I've been responsible for producing a lot of estimates over the past 10 years. I'd have to say it's probably one of the most stressful times in the entire project for everyone involved. Regardless of the length of the engagement, everyone is the same when making a big purchase: tell me how long it's going to take, and how much it's going to cost.

Because of the complexity of the software development process, the frequent ambiguity of initial requirements, and the unknown unknowns of the project, the answer is often "Well, that depends." Our ability to come up with a final precise number early in the process is constrained by a lack of information about what the system is going to do and several months worth of decision making that's yet to be happen.

With that in mind, here's my seven tips on how to improve the quality of a software estimate.

1. Aim for accuracy, not precision

The subtle difference between accuracy and precision is the most overlooked aspect of estimation. Customers ask "How much is my project going to cost?" and the gut reaction is to come back with a single number. Single numbers (like the number 17) are precise. They are exact. But they might not be accurate. Accuracy is all about how close your number is to the final number. And accuracy at the start of a project is difficult to achieve due to the large amount of uncertainty on what is going to be implemented.

So to achieve accuracy, expect a range. Between 10 and 30 is accurate when the final value is 17. It may not be precise, but when faced with uncertainty around precision, an accurate range of 10 to 30 is better than an over-inflated, but precise, single number or 28 if the final amount is really 17.

2. Provide as much detail as possible

More often that not, a brief one page overview of an application is not enough to get a good estimate. The more detail the better. If you can provide a specification document, sample mockup screens, technical architectures, use case scenarios: all of these project deliverables shed light onto the mystery of what you're trying to build. The more of this material a developer has access to, the better informed they are. The better informed they are, the more likely the chances are that they will be able to provide an estimate that accurately reflects the effort required to build your final product.

3. Invest in some up-front analysis work

Don't have the detail? Don't have a 50 page spec and a stack of 85 wireframe screens that describe the entire application? Prepare to invest in some up-front analysis and design work. Often, we'll engage a client in some up-front analysis and design work and once we're done, we'll fix-price estimate on the rest of the project. The client gets some useful design documents that accurately describe the system, we get a much better understanding of what it's going to do, and we're now able to produce valid estimates for the rest of the development.

4. Don't play the guessing game

Every software professional will trot out the "iron triangle" of constraints at some point: features, cost, and schedule. That never seems to stop the requests for the most features for the least cost in as short a period of time possible.

The cost corner of the triangle is a very important one, and is often known, but hidden during the estimating process. Don't make the developer guess. The cost anchor on the triangle is just as important as the features you want or how long we have to build them. If your budget to finish your bathroom is $5,000, not $20,000, then different decisions will be made on how it is finishing. Bye-bye marble countertops, hello laminate!

5. Pick a corner

How flexible are you in your features? Willing to get rid of a few? How about that timeline? Is that September date really crucial? And that budget... any contingency built into there? Knowing your degrees of freedom for each of the corners of the features, cost, schedule triangle is crucial. Estimation is a process of negotiation and knowing where you stand firm and where you have flexibility is important to determine and communicate.

6. Iterate your estimates

Not willing to invest in some "big design up front" to come up with your fixed price estimate at the start of the project? Then prepare yourself to forge ahead and live with some uncertainty at the start, but expect ranges of increasing accuracy as the project moves along. Iterative estimation attempts to incorporate what it learns along the way, increasing accuracy as it goes forward, with the ranges becoming closer and closer together. This reflects the reality of the "cone of uncertainty" that all software projects travel through, well-documented by Barry Boehm in his studies on estimation.

7. Targets vs. estimates

Estimating is a bottom-up approach: on a feature by feature, screen by screen basis, how much effort will this take? Targeting takes the opposite, top-down approach—choose a desired end-point and works back from it (i.e., your budget of $100,000). But the bottom line is the same—your budget and features will often be at odds throughout the project. And there's no guarantee that your target of $100,000 and your project list of 258 features will match up nicely. For anyone that's built something before, software or otherwise, this will be no surprise.

In summary, estimating is tough. To achieve accuracy and precision requires a lot of hard work, both for those producing the estimate and those on the receiving end. It's an imperfect process and one that can have a huge impact on the life of your project if not done correctly. So give yourself some time, invest in some up-front work, and be realistic. Your project will be better because of it.