The True Value of Software Estimation (it’s not the estimate)

Why there is value is estimating software projects even when the estimates are always wrong.

As software practitioners we are bad at estimation. Software tools and languages have improved over the years. Our ability to estimate how long something will take has not. We are clueless.

Why We are Wrong

It’s not our fault. We are humans. We are not good with time. We are constantly wrong about how much time we have. Calendars are overbooked. We are often late. Under the influence of alcohol, even a small glass of wine, we quickly loose track of time, not until much later do we also loose track of distance and location.

Our poor sense of time in combination with our tendency to overestimate our ability to predict the future constantly gets us in trouble. Yes, of course we can deliver features X in five weeks, even if we have never built it before and only have a vague understanding of how it actually going to work!

Software development is design and not manufacturing. It’s possible to accurately estimate a manufacturing process that does the exact same thing over and over again. Most software projects, however, don’t do that. Not even the 101:th Wordpress site you build is exactly the same as the first.

And then there is the so called Anchoring Effect. If the CEO says she needs the feature in two weeks and asks the team to estimate, most likely the estimate will be in the ballpark of two weeks. In reality, it may take two months, or two days.

The most correct answer to the question How Long Will it Take is almost always “I don’t know.”

Damage Control

In recent years, with the Agile methods, we have gained some tools to deal with our inability to deal with time.

1. We use a relative Point System because we are better at relative measurements (is x bigger than y?) than with absolute time (how many days does X take?).
2. We play Planning Poker to avoid group thinking and bias.
3. We break large projects into two-weeks sprints so we more easily can track progress, or the lack of progress.
4. We let the people that is building the software also do the estimates of how long it will take, instead of the project manager or someone else who is not directly involved in that process.

Do any of these methods guarantee correct estimates at all times? No.

So What’s the Point?

If you know something does not work and you anyway keep doing it over and over again and expect a different result, you are insane.

For several years it’s been clear to me that software estimates are wrong, but I still urge all teams to estimate and plan their sprints. As a Product Manager I get estimates from the team and share it with the management team. I do not believe I am insane. Here is why.

The true value of estimation is evident in the following conversation from one of our Estimation meetings. After the Product Owner has explained the Story, and the team has added a few extra acceptance criteria and asked some questions, the team cast their votes, in points using Planning Poker. It goes something like this:

Lisa: -”I give this Story 8p.”

David: -”What!?! I voted for 3p, at most. This is easy.”

Lisa: -”But we need to upgrade the database, that impacts other services. We need to test a lot and deploy everything again.”

David: -”Dammit. You’re right. That’s a hassle. Okey, well 8p then. At least!”

Fredrik: -”I voted for 1p. “

Everyone: -”!?!”

Fredrik: -”We don’t need to touch the database at all. We put the data into the ElasticSearch engine and we’re done.”

All: -”Yeah you’re right. Okey, 1p then.”

What happens here? Because every team member voted (without knowing what everyone else voted), we found out about three different solutions. One was much easier than the other. The members were forced to explain the solution to each other, convincing each other about the best solution to the given problem. This would not have happended without the fact that members gave estimates, which they had to explain.

So what is the true value?

1. Quality — a poor solution is identified early.
2. Productivity — the best solution is found.
3. Competence — knowledge (in this case, ElasticSearch) is shared with the rest of the team. Lisa and David did not know what could be done. Fredrik knew. Now, everyone knows.

So we may still now know how long it’s going to take. But we know what we build will have good quality, we will be productive and competence will increase. At least that’s something.