Save Time and Frustration – Stop Estimating Backlog Items in Hours

In a recent client conversation, the topic of estimating backlog items in hours came up. It seems that I stepped on a hornet’s nest when I suggested that the client adopt a relative estimating approach rather than estimating new requests in hours. I was surprised.

The thing is, the process of estimating in hours is a long-standing tradition. And it turns out, it is usually wrong. Here are some reasons why you should stop estimating in hours.

Why You Should Stop Estimating in Hours

1. You Suck at It – Yes indeed, as humans we are all collectively not great at estimating how big things are or how long things will take. It is especially difficult when items are big.
2. Team members rarely agree on hours – Rarely do two team members agree on how long things will take. Besides the obvious question of individual productivity, there are just too many variabilities and assumptions. Which is why the hourly estimates are most frequently made by just one person.
3. One-Person Estimates Don’t Foster Buy-in or Shared Understanding – That one “smart” person doing the estimating in hours is rarely the person doing the work. That person probably doesn’t have to live with the estimate. I cannot tell you how many times I’ve heard, “who thought that this could be completed in 5 days?” Plus, this approach doesn’t leverage crowdsourcing the way that planning poker or affinity estimating can. So we don’t get the benefits of all team members’ perspectives.
4. Hourly estimates create fear and gaming – I learned a rule of thumb nearly 30 years ago about estimating work that I have heard repeated many times since. Take your best guess of the hours and then double it. The reason for this doubling is that first, we don’t know. And second, we are afraid of being wrong. Better to have a big estimate that we can certainly accomplish (even if that means dragging out the work). This is particularly dangerous when we are measured on our delivery to the estimate, or the variance between what it took and what we thought it would. Those two numbers tend to magically converge if managers focus on them.
5. Estimating in hours tends to ignore non-development work – Frequently when someone gives an estimate in hours, it only includes the development time. Testing time and any other tasks are either ignored or given as a fraction of the development time. How accurate is that?
6. Estimating in Hours Consumes Time and Effort that would better be spent elsewhere. May as well spend time doing the work rather than making poor guesses about how long it will take.
7. Hourly Estimates don’t help you predict throughput. Hourly estimates are usually compared to the theoretical capacity of the team to come up with forecast dates. Unfortunately, that is rarely accurate. Just because you have 5 tasks that are estimated at 8 hours, that doesn’t mean you will get all 5 of them done in a 40-hour workweek.
8. Activities vs. outcomes. Similar to the previous item, the focus of hourly estimates is on the activity. That shifts the focus away from the outcomes that the team is producing.

What You Should Do Instead of Estimating in Hours

1. Ask Yourself WHY Do You Estimate?

Step back and examine how estimates are being used. Can you eliminate estimates altogether?

Before you gasp in shock, consider that most estimates are wrong so if you are using estimates to predict go-live or delivery dates, those are probably wrong as well. Right? Is that the way things are working out for you? Well, why continue to cling to those inaccurate forecasts?

The other common reason for estimating in hours is to be able to compare cost and anticipate the value of the items to decide which should be built first. This is the ‘biggest bang for the buck’ approach and it’s not a bad idea. But you don’t need the false precision of hourly estimates for that exercise. You can use t-shirt sizing of both cost and value to get a faster and precise enough answer.

If you really want your head to explore, check out the #noestimates movement promoted by Woody Zuill. A good starting point this video on the Agile Alliance site.

2. Use Story Points

With new agile teams, I usually train them on how to use story points and relative estimation. It tends to be precise enough and much better at predicting the future than hourly estimates. Story points are simpler and faster, so why not use them, at least as a starting point?

But please don’t fudge by translating hours to points and vice versa. You just undermined the value of the points. Once you lock in a conversion rate (say 1 point = 8 hours), teams can no longer improve their velocity without working more hours. Congratulations, you got your hours at the cost of double the work.

3. Better yet use Items Counts

My colleague Tom Cagley has me convinced that even story points are overkill and a simple count of the items completed is not only faster but more accurate. And you don’t even have to worry about things being the same size because it all comes out in the wash.

Though I do recommend breaking backlog items down – big items tend to hide risk and are hard to complete in one sprint. In any case, item counts shift the focus to what got done – throughput accounting – and that tends to be more accurate, useful, and much much faster.

You Probably Will Ignore This

I know that most of you that estimate in hours will ignore this. I’ve had the discussion enough to know that you will cling to the hourly estimates like a lifeboat. So if you really must provide estimates in hours or days, why not just spin the wheel? Chances are you will be just as accurate. And you’ll save yourself a lot of time and perhaps have more fun using the wheel.

Cheers,

Anthony