Thoughts on Estimates

“How long will it take to be done?”
“When can I expect that?”
“When can X be handed over to Y”

Estimation is seemingly everywhere when it comes to software development, and “I don’t know” or “as long as it takes” doesn’t really cut the mustard as a reply for obvious reasons. There is something fascinating about estimation in that I find it completely rational to ask for an estimation, but equally annoying. I find myself becoming instantly combative whenever I’m asked to do an estimation on some work. One factor that could be behind the frustration surrounding estimation is that some estimates feel “informational” whereas others are simply “commitments”.

When an estimate is providing some information to someone, it feels to me to be a completely reasonable request. The issue is that once the estimate becomes more like a commitment, there seems to be only downsides to giving an estimation. It feels as if by giving a particular time frame, there is no benefit to meeting that timeframe, but definite disappointment if the thing isn’t delivered in the timeframe chosen. This is a problem, because estimates are asymmetrical. They are rarely very early, but they are often very late. This is because at the start of a piece of work is when we know the least about that piece of work. We cannot foresee the problems we will encounter without getting stuck in first.

The Drive Analogy

Let’s say you have a long drive ahead of you, say roughly 10 hours on the motorway is your estimate.

• If you really put your foot down and broke the law a little, you could maybe shave 1 hour off that journey — hardly significant.
• However, if you sat in traffic because of an accident there’s no saying you couldn’t be another 10 hours late.
• Even worse, you could break down, get towed and spend an extra night in a hotel waiting for your car to be fixed.

These aren’t even the most severe scenarios but they demonstrate the asymmetry of estimation:

• You could only shave ~10% off if everything went perfectly.
• But with any deviation, you could lose 30% (or more) quite easily.

The same can be said for software projects. If you estimate a project to last 10 weeks and you manage to smash it out in 9, that’s quite an achievement. More likely though, it would take much longer — maybe 20 weeks or more, especially if the estimate was made very early or at the start of a project. Even worse, estimates can be made by others who aren’t going to do the work, putting that weight over someone else’s head.

What Does Scrum Say About Estimates?

First of all, Scrum does not have a preferred estimation technique. It is a light framework, so it can be used with poker planning, Monte Carlo, or whatever estimation method you like.

It also doesn’t say anywhere that estimations should be stopped altogether, like some commenters believe on t’interwebs. It does, however, recommend a timebox instead of estimates.

According to scrum.org, there are still 5 reasons to estimate:

1. Coordinate dependencies
2. Align priorities
3. Choose best value option
4. Forecast the weather
5. Shared understanding

There is also an emphasis on readjusting estimates. Estimates should be updated during the sprint as more feedback is gathered. As the team works together, information is gathered about how many relative units of work the team can produce in a sprint. Then it should be theoretically easier to predict how many sprints the work can be fit into.

When Not to Use Estimates

There are also times when estimates shouldn’t be used at all:

• If they are used as a way to pressure people to work faster → disaster awaits.
• If they are used for time management → doomed to fail, because estimates are wrongest at the very start.

The challenge here is advocating for better work practices all around, which is easier said than done. The old school waterfallers and Wagilers are still in every business and by and large haven’t updated their ways of working for 30 years.

Cone of Uncertainty vs Scrum

In traditional project management, the Cone of Uncertainty is used to show increasing accuracy of estimations as the project goes on. Projects were completed in phases, so by the time the requirements phase was completed, the next phase could begin.

Scrum, however, doesn’t have requirement or design phases. Instead, it uses a sprint, a time-boxed container in which the objective is to get to a DONE increment.

My Current Thinking

I’m still very much working out how to approach estimates.
I still find most of the estimates I’m asked about rather pointless, but I’m trying to advocate towards a more agile approach.

By that I mean:

• Preparing the team for change.
• Using estimation to inform, not to punish.
• Remembering that uncertainty is always higher at the start.