Estimates

When you are planning out a large software endeavor (or even a small one!), you want to make sure you get the most bang for your buck.

Typically, this results in a long spec sheet with desired features of the software, which is then passed to the development team (contract or in-house).

The team will then analyze the list, assign “points” to each. The team then has some kind of internal mapping between those points and an approximate amount of time each will take.

Once complete, the estimate is then passed to the business with both the time and funding it would require nice and clear.

Sounds infallible, right?

Nope. In fact, estimates in software are becoming more and more of a joke in the business world. Instead of adding 10% or even 20% margins, more and more companies are being forced to add 100 - 300% margins because they know it’s likely to be wildly off.

Why?

1. Lists of features hide inherent behavior. It isn’t until you explore how to actually implement a feature that you realize not only that there are 10 different ways this could manifest, but all of the ways it may be able to interact with all of the other features. This causes cascading changes and updates which very quickly blow the original estimate out of the water.
2. The Point-Time mappings tend to be pretty good at low point values. The variance becomes exponentially worse the larger the points become. Understanding why is pretty simple. The more complex the feature, the more uncertainty. Rather than being a sum, it’s a product. Compare this to dice… 1 4-sided dice would average to 2.5 with a range of [1, 4]. If you are off, it’s only by a bit. Add just one more dice, and our average becomes 6.25 with a range of [2, 16]. 3 dice becomes far worse, with the average of 15.625 and a range of [3, 64]. Now, that single task estimated at 15 days might take over 60… over 4 times as long as anyone had expected.
3. Most development teams have little to no skin in the game. If their estimate is off, the founders will get angry at the team lead, he’ll come back to the team, and the whole team will make fun of those business guys who just don’t understand how engineering works haha.

This has caused an entire movement called #noEstimates. They claim the following:

Estimates don’t provide value.

Estimates are almost always wrong.

It’s better to just be reactive, pay hourly prices, build small, and react quickly to feedback.

And, they’ve got a few good points, but they miss one massive elephant…

Businesses want estimates to compare cost to value. If moving in a particular direction will cost more than the value it will bring, they want to avoid moving there at all.

If only there were another way of doing things…

(to be continued)