Never miss one of my articles: Readers of my newsletter get my articles before anybody else. Subscribe here!

I am still thinking about estimates and #NoEstimates, and I am still writing my findings down here. In the last article, “A Spectrum Of Effort Estimates”, I wrote about different ways of estimating software development effort. Today, I want to explore what an estimate really is.

Definitions

In discussions about estimation, planning and #NoEstimates, I have experienced that people use quite different definitions for what an estimate is. So the discussions often lead nowhere because the participants are talking about completely different things and misunderstanding each other.

Here are three different definitions I have found. You will probably encounter more.

Estimates, in the context of #NoEstimates, are all estimates that can be (on purpose, or by accident) turned into a commitment regarding project work that is not being worked on at the moment when the estimate is made.

-- Vasco Duarte, "What is an Estimate?"

I think this definition is not very helpful as a definition of an estimate. First, it references itself (“Estimates are all estimates that…”). Second, everything you say can be turned into a commitment by a sufficiently malicious or careless person. On the other hand, this definition is helpful in understanding why estimates are often problematic: We don’t want our estimates to be turned into commitments. Especially not by somebody else. This definition also hints that there are some estimates we want to avoid in #NoEstimates, and others that we are less concerned about.

An estimate is an approximate calculation or judgement of the value, number, quantity, or extent of something.

-- Giovanni Asproni, "Learn to Estimate"

This definition is helpful in a way, because it highlights that an estimate is an approximate calculation. On the other hand, it does not tell us what is the exact difference between an estimate and other approximations (rounding, …).

An Estimate [is an] approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.

-- Wikipedia: "Estimation"

While quite similar to the definition above, this definition adds some interesting aspects: The approximate value was derived from incomplete or uncertain data. Still it is usable, because we used the best information available to create it.

Effort Estimates

When we talk about “estimates” in software development, we often mean estimates of the development effort. That is, estimates that try to predict how much work a task, user story, use case, feature or product might be. Or how long it might take.

We use those estimates to predict when something will be done, how much functionality we can implement in a given time frame, how much developers we need for a project, and so on. We also use them to decide what to work on next, if we should even start a project, and other things.

Estimates everywhere

In software development, you can find estimates everywhere. Some of them are explicit, like the story point value on a user story. Others are implicit, like “Tasks take just about one day, because when we split a story into tasks, we try to make them short”. Some of the estimates will estimate development effort, some will estimate other things (like the performance impact of a feature).

What do you estimate explicitly in your team? What implicity estimates do you have, and which ones would you rather make explicit? Did you ever experience any problems with your estimates? Please tell me!

Oh, and if you have any questions, Just ask ;)