The Real Reason We Estimate

Get insights in your inbox

Over the past few months, various blog posts have popped up talking about estimation, how estimation is unnecessary, how estimation is waste… and that maybe we should stop estimating entirely and just get down to the business of writing software. If our estimates are always wrong, and most of the time they are, why should we even attempt estimating in the first place?

Agilists eschew absolute estimates in favor of relative estimates, and absolute values to estimates made in more abstract units like story points. Story points are measured in non-linear sequences like Fibonacci to further abstract their value from any notion of absolute time. As a result, agile estimates are only relevant in the context of a stable team with a known measured velocity.

Many teams aren’t any better with agile estimating than they are with traditional estimating and I think this is what leads many folks to reject the notion of estimating entirely. If agile estimating doesn’t work any better than traditional, why bother estimating at all? Personally, I’m a big fan of estimating and teach it to all the teams I work with. Estimating can work… but only if you understand why you are doing it.

You see… estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, its almost never an estimating problem, it’s a shared understanding problem. If you can get to the bottom of your shared understanding problem, you will fix your estimation problem.

Shared understanding problems can result from any number of organizational dysfunction’s. Some of the most common are on the product side… insufficient business involvement, insufficient understanding of the business problem, and insufficient requirements decomposition tend to result in sprint planning meetings that are too long and not detailed enough.

When there there is too much of the wrong kind of discovery going on during sprint planning… teams will get tired and frustrated and end up committing to the sprint deliverables without sufficient understanding of what they are going to build or how they are going to build it. They’ve estimated and discussed, but they’ve never gone deep into the details. This always results in too much discovery going on during the sprint, too much unanticipated work, and too many missed deliverables.

The other big shared understanding problem comes from technical debt… poor architecture, quality problems, or even just teams that are unfamiliar with the code base, all result in making commitments without a clear understanding of what work actually needs to be done. When you couple a general lack of understanding about the requirements, with a general lack of understanding about the code, it’s no wonder people are frustrated with estimating.

Giving up estimating is basically giving up being able to give the business any idea of what they are going to get or when they are going to get it… even at a high level. My take is that we can’t give up estimating, we need to get better at estimating, but that means that we need to get better at creating shared understanding. It’s my opinion that creating shared understanding is the main reason we estimate.

It’s not so much the number that matters… it’s the shared understanding matters. If we are estimating without creating shared understanding, we are missing out on the value, and the estimates will always be poor. If our estimation process increases the level of shared understanding, our estimates won’t necessarily be right, but they should be consistent… and consistency is all we need especially for establishing a stable velocity.

So… if we want better estimates, or at least more consistent estimates… our goal isn’t better estimating, it’s more shared understanding. The question now becomes… how do we create more shared understanding?