Thread by @tPl0ch

There are so many different opinions about cost estimations in software, and many of these are rooted in estimates being used as measurements, targets or commitments. I want to clear up some misconceptions regarding estimations.

A thread 🧵1/n

#NoEstimates #ProEstimates

The first thing we need are some definitions. One major driver of confusion are the various interpretations of the words "estimate" and "estimation".

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

This definition does not mention *what* will be estimated and *how* these estimates will be used. And that's normally where the arguments start, since everyone is making different use of them.

I'll try to summarize the most common uses of *what* is estimated first. 3/n

1. Absolute cost of dev.

This can be anything like person-days, team-weeks or monetary value. With these estimates you normally want to answer questions like "can we deliver this scope within our budget constraints".

Absolute cost estimates are every accountant's wet dream. 4/n

2. Relative cost of dev.

These estimates use an abstract representation (i.e. story points) and compare the story at hand to a benchmark. Abstract scales give teams the ability to factor in other dimensions like complexity or risk.

"How much work are we actually doing?" 5/n

3. Time of completion

The classic answer to "when will it be done". While you may think that "absolute cost of dev." and "time to completion" are equivalent, they are very different in nature. I.e. "do whatever it takes to finish by X" vs "we only have a runway of X months. 6/n

When we look at the previous descriptions of *what* is normally estimated you can see that they are all, one way or another, referencing some constrained parameter - the capacity of the team, the financial runway of the company or the due date of a contractual obligation. 7/n

So let's investigate why people dislike providing estimates. This has a lot to do with *how* estimates are used in organisations, and here especially with how they should *not* be used. The following examples probably hit home with a lot of people. 8/n

1. Estimation as a ritual

Your team is just estimating stories because some version of the Scrum guide briefly mentioned it. There is no real use except trying to answer questions like "will these stories fit into our X week iteration".

Stop this right now, this is waste. 9/n

2. Estimates are treated as targets or commitments

You are asked for single-point numbers and are held accountable for the correctness of the estimates.

These are no estimates, you are just providing commitments to implicit targets the stakeholders hide in their heads. 10/n

3. Estimates as a measure of performance

"Our team averages a velocity of 34.68 story points per iteration."

Using any computed value from estimates to measure performance is a road into disaster. Stop it.

Rather measure throughput/flow of stories through the pipeline. 11/n

Most negative experiences with estimations can be categorized into the three previous examples - if you have other examples please let me know in the comments.

So now that we have talked about the pitfalls of estimation, let's see what estimates are actually good for. 12/n

The only *valid* use case for estimates I see is supporting constrained decisions that have to be made under a high degree of uncertainty and a low information density.

In these scenarios an iterative discovery is normally not viable because of the decision constraints. 13/n

But why are estimates so valuable in this scenario?

Decision theory defines the concept of "Value of Information". It "is the amount a decision maker is willing to pay for information prior to making a decision".

With a low information density, any information is valuable. 14/n

Unfortunately the VoI is not constant.

The more information you gather, the less valuable each new piece of information becomes.

Additionally the more information you have, the higher the cost of finding new pieces of info.

So there is a limit to viable discovery. 15/n

That means that in the absence of information even estimates or educated guesses have a high Value of Information.

Paired with the "rule of five" - a 93.75% chance that the median of a population is between the min and max in any random sample of five - it becomes useful. 16/n

I hope I could clear some confusion regarding estimates and their usefulness. In short almost all uses of estimates in software are useless. The really valid use cases are seldom in nature - constrained decisions with a high degree of uncertainty and low information. 17/17