There are some things that are really easy to agree on when it comes to estimating:

• Estimating is important.
• Estimating is hard.
• Estimates are always wrong.

Of course, there are some fundamental problems with how we estimate. Traditionally, the question we are asked when it’s time to estimate effort is “how long will this take?” If you’re still asking this question, I respectfully suggest you’re doing it wrong. In fact, you couldn’t be doing it more wrong. Study after study has shown that estimating complex work in hours (or any time-based unit) is the worst way to approach it. In fact, you’re better off not estimating at all than to take a SWAG at how many hours something will take.

Why is this?

The truth is that estimating in hours or days actually creates a losing situation for everyone involved. To start, the second you provide that estimate, you’ve essentially signed a contract that says “I will do this in a fixed amount of time”. That’s not what you meant to do, of course, but that’s almost invariably what happens. There are now three things that can happen:

• We hit our estimate exactly. This actually never happens, but I suppose it’s possible, so I will leave it here.
• The work takes significantly less time than expected.
• The work takes significantly longer than expected.

Starting at the bottom, when something takes longer than expected this leaves us feeling like something is wrong. This work should be easier and it should only take so long; the problem must be that I am not as good at my job as I thought. Get caught in this trap and the thing that is already behind starts to fall further behind as you begin to question yourself on everything you write. It’s pretty clear why this is bad.

But when we take less time, that’s not bad, right? Guess again. There are two common scenarios here too, neither of which are good. The first is that we can find ourselves wondering what we missed, and start to second guess ourselves. We start reviewing every line of code and looking for the obvious mistake that we didn’t account for, and start to gold plate the work that is perfectly fine! The other thing I have personally seen is that we leave a user story marked open with some hours left, and when another one runs longer, people start “working” on the completed item to steal away a few hours so that they stay on track and their burndown looks good. Never mind transparency, it’s about making sure we don’t look bad.

We suck at precise estimates. Don’t let anyone try to convince you otherwise. We are, however, really good at judging if Thing A is larger or smaller than Thing B. Or at least, we’re reasonably better at it, which is close enough.

Story Points have become widely accepted because it gives us a way to estimate and remove time from the equation. If Thing A is 3 points, and Thing B feels slightly larger, it’s likely 5 points. We’re good. How long will a 3 point story take? I have absolutely no idea. The size of a story and how long it will take to complete have no relationship to each other. Even in a world where we could easily make that determination, it would vary from team to team. And that’s all totally okay. Remember that estimates are always wrong. An otherwise meaningless number that says “this is bigger than that” is really all we need to know. Given enough time estimating this way, rather than using hours to load up to exactly how much time in in a Sprint, we will get a clearer picture of how much work a team can accomplish, and they will actually go faster and with higher quality.

I use a game to coach my teams through improving how they estimate.  I’ll share more about that in my next post.

Don’t let your estimates trip your teams up. The more vague you are, the more accurate you become!