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.