My Team Always Estimates Wrong

Recently I was in conversation with an Engineering Director who was lamenting the fact that his development teams are frequently off on their estimates by significant margins. For example, estimating 2 weeks on a feature and then taking an entire quarter to complete. Now, very few teams are able to estimate work accurately which is why we lean away from doing them as much as possible but this is a significant miss even from a high level guess. So, why does this sort of thing happen?

Why is it hard to estimate?

There are a number of things that can cause a team’s estimate to be missed. Here are a few:

1. The feature is complex

2. The feature involves systems the team is unfamiliar with

3. The code is complex

4. Teams get interrupted with other priorities

5. …

One reason that gets overlooked that I want to discuss here is simply the technical skill level of the team. I’m not talking about their estimation skills. I’m talking about their general development skills.

What do technical skills have to do with estimation mistakes?

Let’s say you have a development team with a couple of developers who are at an intermediate technical level. They’re fairly comfortable with the stack you use and how to get features into production. But, they’re not at a senior level in terms of all the various software development skills that make a strong developer. (Side note: there are a lot of seniors who are weak in many of these skills too) One might think that, yes, it will take this team a little longer than a more skilled team to accomplish things but that just means their estimates will be longer. So why does a team keep missing its estimates by such wide margins?

One of the main reasons is that the gaps in skill level cause extreme variability in the time it takes to complete something.

Let’s take an example: A task that is deemed by the team to be simple enough to complete in the range of one hour. In this case, we’ll compare a high level skill difference of “debugging”. For this example let’s pretend “debugging” is a singular skill.

We’ll compare 2 developer flows:

• Developer A is a highly skilled developer who has honed their debugging skills to a strong level

• Developer B is a lower skilled developer who understands at a high level that debugging means “fixing a problem” but hasn’t yet learned the skills required to be strong at it.

Assume that, essentially, the rest of the skill levels are equal. Let’s take a look at how the development flow might go:

Developer A’s flow:

• Perform some initial work (25 minutes)

• Run into bug

• Debug quickly (5 minutes)

• Get back to task and complete it (45 minutes)

• Head off to team meeting

Developer B’s flow::

• Perform some initial work (25 minutes)

• Run into bug

• Struggle to determine if it is a bug (45 minutes)

• Head off to team meeting (1 hour)

• Resume debugging

  • Rebuild mental context (10 minutes)

  • Is it a bug with my changes? (30 minutes)

• Conversation with colleagues about a previous change (30 minutes)

• More interruptions

• Resume debugging

  • Rebuild mental context (10 minutes)

  • Yes, something I’ve done was wrong (30 minutes)

  • Figure out what’s going wrong (30 minutes)

• End of day

• Pick up again next day

The difference in this one skill has caused an estimated one hour task to stretch from 1.25 hours for one developer to beyond a full day for the other.

Now add in another skill deficiency and run the simulation again. In many cases the deficiencies compound and suddenly a one hour task has spanned 3 days. Add in the fact that estimation gets harder the longer the task is and you can see how something that was estimated at a couple of weeks suddenly explodes to 3 months.

Conclusion

Could the team have estimated this task better? Sure, you could have padded the estimate to account for variance in team skill. Does that provide the business the information they need to make appropriate decisions? I’m doubtful.

So, yes, estimation is a skill that can be improved but I’d argue that estimation itself is not the problem. If you’re missing estimates by wide margins then have a look at your team skills. Telling teams to estimate better isn’t the answer. Find the skill deficiencies in the team and address them. It’s hard work but the payoff is enormous and as a nice side effect your estimates will start to get more accurate.