Basic Software Estimation Concepts

In one of my recent posts I was writing that single point estimates are meaningless. In this post I would like to carry on with this topic and talk about a few other fundamental concepts for software estimation based on Steve McConnell's "Software Estimation: Demystifying the Black Art".

One of the most important things is to know the difference between estimates, targets and commitments.

While 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 than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.

It's quite typical situation when developers are asked to estimate new project or piece of functionality for which deadline is already set. You have to know if you are really asked to provide estimates or to figure our how to meet a deadline. Those are two totally different things. Estimation should be unbiased therefore deadline doesn't matter. If deadline matters then you are, in fact, asked to provide a plan in which goal is to deliver before the deadline.

Single point estimates are meaningless, estimations should always be represented as a range -- the best and the worst scenario. Don't estimate only at the beginning of a project. At every stage estimates can be useful and they can show that project goal is in danger.

Once we make an estimate and, on the basis of that estimate, make a commitment to deliver functionality and quality by a particular date, then we control the project to meet the target. Typical project control activities include removing non-critical requirements, redefining requirements, replacing less-experienced staff with more-experienced staff, and so on

Controlling the project include dealing with changing requirements. But with new requirements estimations also change and after a few iterations your target is to deliver something radically different then it was estimated at the very beginning. How can you say then if initial estimates were accurate?

In practice, if we deliver a project with about the level of functionality intended, using about the level of resources planned, in about the time frame targeted, then we typically say that the project "met its estimates," despite all the analytical impurities implicit in that statement.

If it's well known that assumptions will change, functionality will change then what is the real purpose of estimates?

The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them.

Important implication is that gap between estimates and actual times has to be small enough to be manageable. According to book, 20% is the limit which can be controlled.

Estimates don't need to be perfectly accurate as much as they need to be useful. When we have the combination of accurate estimates, good target setting, and good planning and control, we can end up with project results that are close to the "estimates."

That takes us to a definition of "good estimate"

A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.

All of that and much more can be found in the book, it's worth reading.

Single point estimates are meaningless

How useful is statement "We estimated that project X will take 6 months"? What does it exactly tell you? Does it mean that you can be sure that the project will take 6 months? It's obvious that you can't be sure of that ... so if you were to sign a contract what would you do? It's quite typical approach to add 10% or 20% "just in case" which, in normal thinking, should guarantee meeting a deadline right? The problem is that single point estimates like 6 months for project X are useless without information about probability of success. Let me explain what I mean by that ...

Estimates are based on assumptions, specification etc. ... general rule is that estimates can be as accurate as details you have. So if you have only vague idea about the system then due to uncertainty your estimations can be really far away from the actual time. Some books are saying that actual time in such cases can be 4 times bigger the the estimate but it is also possible that it can be 4 times smaller! In our case, it means that the project X estimated for 6 months can take 1,5 to 24 months! Horrifying, isn't it?

Precision of estimates can be improved from ±4x to ±1,25x by providing details, that is why specification (requirements, UI design, use cases, acceptance criteria) can be so helpful.

What is the conclusion?

A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets‥

Single point estimate doesn't provide a clear view, I believe that to have a clear picture it's required to know the best case and the worst case estimates. Then probability of success can be illustrated like this:



In the best case project will be finished in 20 weeks, but there are only 10% chances for that. In the worst case project will take 32 weeks, but also after week 28 we have 90% chances to get everything done. With those data project manager has a clear picture and can decided what risk is willing to take and plan accordingly.

So if statement "We estimated that project X will take 6 months" is meaningless then how should estimates be stated? Try to use ranges and rephrase statement to "We estimated that project X will take 5 to 7 months". Sometimes, when uncertainty is big, the range between best and worst case can be significant, but wide range is not a result of bad estimation, it's a result of lack of specification!

Data and definition of "good estimate" used in this post are from "Software Estimation: Demystifying the Black Art" book.