I was in the middle of a discussion with some folks about estimation. Few topics create a ruckus on command as estimation does. That conversation led me to realize that there are many more ways to estimate than people often consider, and I thought I’d run through a few.

Obligatory Warning

Estimates aren’t accurate. Most people understand this at an intellectual level but still get upset when the estimate turns out to be wrong. Estimates can give rough information, but estimates are the wrong tool if you need to make serious predictions.

Relative Size

This is probably the most commonly taught technique that you see practiced the least. At its core, you estimate things as they compare to other things.

So if you have a pile of work, you pick one and decide which ones are bigger, smaller, or the same-as. I wrote an article on a fancier version of this called affinity estimation.

The nice thing about this technique is it is quick to do, gives a rough sense of things without too many debates about what numbers mean.

Planning Poker

Planning Poker is the most widely used estimation technique for most teams pursuing agile. It involves everyone revealing an estimate simultaneously, then resolving major differences through discussion and re-estimation.

There are some good elements when planning poker is executed well. For example, having everyone reveal simultaneously is one of the key elements to its effectiveness. If one goes first or one does the estimates, the rest don’t matter. There will be too much bias in the room. Next, the conversation about why there is a difference is when assumptions are vocalized often for the first time. This conversation is the real value of the whole thing and can be replaced with more direct questions.

Another thing is that many tools provide mechanisms to do planning poker as a built-in benefit. So even if you’re not sure how to do it well, many tools have the basics available.

What sucks about this technique is that it does encourage a fixation on numbers, and those numbers are inaccurate and fail to answer the questions about their purpose, which is asking if it’s too big or not.

Senior First

A variation on the planning poker is simply asking the most experienced folk for their estimate and using that. Have a conversation with everyone around what everyone sees in the work so assumptions aren’t missed, but bypass drawn-out debates by having the most experienced go first.

The benefit here is that we’re front-loading on experience. The downside is that we aren’t always sure if that experience is well-calibrated to estimate.

What I mean about well-calibrated is that we often don’t know what people consider when they estimate. Just because people have a lot of experience, that doesn’t mean they can easily bring a well-rounded and considered body of it to the moment they estimate. For example, did they estimate what they think it would take them working solo, or did they estimate considering the overall team’s capabilities?

Averages

Another riff on planning poker takes advantage of a phenomenon that individuals are bad at estimating, but groups aren’t.

In this variation, you ask everyone to reveal their estimate, and you average it. That’s it!

Discuss what people see in things, assumptions are silent killers, but the estimate part is done.

The wild thing about this technique is that there is some research backing this technique up as effective.

Right-Sizing

This last technique is coming into wider use and is so simple it hardly counts.

Essentially the team picks a size that things can be based on their confidence of things that size. To give you a rough starting point, 1-2 days is common for most teams.

From now on, every work item either fits in 1-2 days or is broken down to fit in 1-2 days. That is literally it.

This technique is really interesting because the smaller the work gets, the more confidence there is in size. This means the estimates of 1-2 days become more accurate. Where it gets interesting is how this holds up with buckets of 1-2 day items. Instead of averaging made-up points and whatnot, you can count the number of items.

There is more about this, but right-sizing has some fascinating implications that go well beyond this article.

Empirical Forecasting

I tend to do this as a stopgap with groups who hate estimating the way they do but don’t want to abandon it for fear of repercussions from mysterious overbearing managers that I’ve rarely found in the wild.

How this works is by looking back at cycle times of previous work. Funny enough, cycle times for most teams tend to hang within two standard deviations regardless of how they get estimated. Another funny quirk is that most teams tend to estimate anchored to around a common number without realizing it.

Those two facts allow me to record the time it takes for work to move through the process, and using the range of numbers, I can simulate the team’s execution over any given period to predict what will happen.

If this sounds like a lot of math, it is. The results are alarmingly good, and with a bit of practice, this is easy to set up. Oddly, while most groups crave the predictive accuracy this provides, they often dislike its answers.

Does It Matter?

I go back and forth on how much it’s worth investing in the topic of estimation. I do find there is a utility to having a sense of how the machine runs, but often this becomes an obsession that yields no benefit.

I think most companies would happily take a volatile and slow team that generated one-million in extra revenue each time it finished compared to a fast and predictable team that only created extra maintenance cost.

So, there you go, a few different ways you can estimate!