< Blog

Estimates are a business function, not an engineering function.

Hero image for Estimates are a business function, not an engineering function.
11 min read

“We just landed one of the biggest deals in our company’s history. To close the deal, we promised the customer a few things. I trust you to deliver this crucial piece of functionality on time, so we don't lose the deal.” The conversation ended with the famous last words: “Don’t worry, what they want is really basic.”

During the deal our CEO, CTO and CPO got together and decided that what the customer was asking for was simple and easy to build. They made commitments to the customer without involving any teams in the process. To top it off they agreed to a date and threw it over the fence as well.

Our CTO told me to “Figure it out”. When questions came up about what the customer wanted those were answered with “Do whatever you think would be best.”


Has that ever happened to you? If it makes you angry consider this - The C-Suite wasn't estimating the time to build the feature, they were estimating the number they needed to win the business. Successfully, I might add - job done by the C-suite!

Now that the business has been won, your job is not to build the new feature in the X weeks, rather it is to manage the customer while the project is completed in whatever time it takes. The customer probably didn't want or expect an X week delivery of specific scope, instead maybe they were just pushing to see how much your company wanted the business, or maybe they actually wanted vague requirements that they could change as the project went along while keeping you (the vendor) under pressure to deliver whatever thing(s) they eventually decide they want.

Managing the customer is now your most important job, not necessarily delivering the feature.

Here's the deal with estimates:

1. Reality is unaffected by (anyones) estimates.

How many pennies are in this jar?

pennies in a jar

Whatever estimate you come up with, whatever methodology you used, I bet your estimate is wrong. It's either more or less wrong, but it's not exactly right.

Now for the key point: your estimate does not influence how many pennies are present. Reality is unaffected by your guess.

The same logic applies to estimating or forecasting software delivery timelines. Delivering a feature still takes a certain amount of time, regardless of the estimate. Software delivery cannot be late or early - it simply takes whatever it takes. It is our expectations that create a perception of late delivery.

2. Estimates are usually a business function, not an engineering function.

Estimates are used to make promises to external customers. Estimates are used to promise features (Elon, when is "full self-driving" going to be available?). Estimates are used to plan future events (e.g., we need to have "X" feature ready for the summer sales conference).

Once you realize this, you can approach estimating differently. You may ask what do we need to know to make this decision? If this feature takes over a year to develop, is it worth doing? Then we can ask the development team "what are the odds this feature can be developed in less than a year?" From there we can make an informed business decision.

Or, if we need something to show at the next sales conference then the question is not "will this specific feature be ready?" but rather "What can we have ready for the upcoming meeting in two months?".

3. All estimates are just predictions.

It’s also generally a prediction we make with too little information. When doing complex work, at the start we know we lack information. Our information and understanding are limited to the extent that getting the estimate close probably means we got lucky, just like when guessing the number of pennies in the jar.

One of the best tools for estimation, I've discovered, is not an estimation technique at all, but a communication technique. My preferred way is to give 30/60/90 estimates:

  • I'm 30% confident it'll be done in 20 days,
  • 60% confident it'll be done in 45 days, and
  • 90% confident it'll be done in 60 days.

If the product manage or sponsor say "great, we'll plan on 45 days," remind them that there's nearly even odds you don't hit that.

If they complain that the range is too wide ("How can it be 20-60 days? I need more confidence!") then you can use that as justification for exercises which increase confidence (prototyping, more detailed planning, research any unknowns, etc).

The important thing is to make it impossible for someone receiving your estimate to ignore the uncertainty in the numbers you give.

4. The only thing worse than estimating is imposing your estimates on others.

Nothing is more frustrating than forcing estimates the team needs to execute on. Because those estimates often will turn out to be incorrect, the team that tries to deliver on them will develop feelings of resentment toward those that produced the original estimates.

If you want buy-in, and better estimates, let the people that execute the work come up with the estimates. Then if the estimates are wrong, which they invariably will be, the team can only point their fingers at themselves.

Throwing estimates over the fence is a sure-fire way to start a blame game where everybody blames each other.

5. Estimates become more reliable closer to the completion of the project. This is also when they are the least useful.

Early on in a project, you know the least, so your estimates will be the least accurate. Paradoxically, this is also the moment when you’d like to know most about the required effort of your project, as you can pull the plug on the project without having to exert any effort.

As the project progresses, you will gain a better understanding and have a lot more information about what needs to happen. Your estimates will become more accurate. However, as more and more of the project is completed, the accuracy of your estimates becomes less important. Also, because of the time you’ve already invested in the project, companies become less likely to quit development.

But don’t be fooled. Even when you’re nearly done, you can still discover something that blows up the whole project. In software development, seemingly small issues can have large consequences.

6. The more you have to worry about your estimates, the more certain you can be that you have bigger things you should be worrying about instead.

Estimates are a red herring. It’s easy to get distracted and believe accurate estimates and meeting timelines are what matters most. However, as said before, it takes as long as it takes.

When teams try to meet the imaginary timeline produced by the crystal ball, tunnel vision creeps in. The only thing everyone sees is the looming deadline. The whole discussion reverts to ‘How can we meet that deadline?’ while ‘Is it good enough?’ moves to the backseat, and ‘How can we move faster?’ climbs into the driver’s seat.

Obsessive focus on ‘When will it be done?’ guarantees you will move [ quality, and ] the delivery of value to the backseat. Yet, "am I doing high quality and high value work?" is the most important question to focus on - even/over "when?".

7. When you suck at building software, your estimates will suck. When you’re great at building software, your estimates will probably still suck.

The ability to estimate accurately has little bearing on your ability to build great software.

Better teams will usually produce better estimates, but those better estimates still aren’t good enough to deliver accurately.

Like the weatherman who cannot predict the weather accurately more than a week in advance, software development teams quickly reach a ceiling in how accurately they can estimate, and how far in the future they can predict outcomes.

Adjust your sails, deal with the unexpected and uncertain, instead of being angry at the winds you will never be able to predict and control.

8. The biggest value in estimating isn’t the estimate but rather creating a common understanding.

When estimating, a different estimate usually means there is a conflicting understanding of what needs to happen. By talking about the work to be done, differences in opinion of what needs to happen surface.

Creating a common understanding is the biggest value in estimation, not the actual estimate itself, which will turn out to be wrong.

9. Keeping things simple is the best way to increase the accuracy of estimates.

Removing complexity and uncertainty, either by doing the work or before you start doing the work, is the best way to increase accuracy of estimates. Keeping things simple is the best way to prevent your estimates from ballooning and blowing up in your face.

10. Building something increases the accuracy of estimates more than talking about building it.

It’s appealing to talk, analyze, design, debate, and do infinite research before starting the work to abolish all uncertainty and risk. However, no matter what you do, you’re still limited to the knowledge of what you can know before starting the work. You quickly experience diminishing returns from trying to draw conclusions based on inadequate information.

By doing the work and starting, you discover the real problems that matter sooner. Work with what you do know to discover what you don’t know. Being book smart won’t cut it, you need to be street smart too. My grandfather always said: "The sooner you start, the sooner you finish."

11. Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that.

Our usual response to produce a better estimate is to sit endlessly in meeting rooms and break everything down to the smallest detail. By doing this, we lose valuable time we could spend actually doing the work. As stated before, this is where you discover the problems that matter.

On top of this, all those elaborate plans are detached from reality and will ultimately slow you down more and more as the project goes on (because you will have to continually explain why your plan is not matching reality).

Sticking to the plan as it deviates more and more is a dangerous thing. It is better to start with simpler plans that are easier to adjust. When you break down the whole project to the smallest details, you create a false sense of precision.

12. Punishing wrong estimates is often like punishing a kid for something they don’t (and can’t) know yet.

Some companies believe that it’s possible to produce perfect estimates as teams mature and become stronger. Therefore, any team that is not able to produce accurate estimates is incompetent.

When you punish teams for making inaccurate estimates, you are likely penalizing them for things that are out of their control.

It’s like punishing a kid for something they can’t and don’t understand yet. It’s a form of bullying that leads to panic and anxiety without producing any tangible benefits.

Stop wasting time on the delusion you will ever be able to produce perfectly accurate estimates

Summary

Past performance is not a guarantee of future results, especially when it comes to software estimation. In 1943, at a casino in the USA, red won 32 times in a row. This is a classic example of the Gambler’s fallacy:

“A failure to recognize the independence of chance events, leading to the mistaken belief that one can predict the outcome of a chance event on the basis of the outcomes of past chance events.” 

Many software teams suffer from a software development counterpart:

“The misguided belief that by estimating more often and working together for a longer period at some point in time, you will be able to produce accurate estimates.”

If you’re confident you’re making the best progress you can towards delivering something valuable, does it make a difference if it’s slower than expected if that expectation was always flawed and imprecise to begin with?

References

Sharing is Caring

Edit this page