Script

Why do we do project estimates?

Before we begin discussing the challenges with project estimates, let's step back and think about why estimates are required in the first place.

So what exactly are we trying to solve by investing effort into producing estimates?

1. Delivery dates - namely, the customers paying for whatever it is we are building will want to know when they will get it.
2. Costs - those customers will also want to know how much that new delivery is going to cost them.

Already you should be seeing that the stakeholders for these estimates are all on the business side, not on the engineering side.

Secondly, its clear that both of those values, dates and costs, are directly driven by the amount of effort required to meet the project scope.

Project estimates are therefore in my mind primarily a commercial topic, rather than a technical topic.

If you work in a software vendor, your sales team will sell a certain amount of work to a customer, and engineering will be expected to deliver that on time and within budget.

If you work in a larger enterprise, you probably have some internal business case approval process to go through before a project budget is approved, but the basic principals are the same as a vendor (your customers just happen to be in-house).

And so, the age-old dance begins between the effort that has been sold by sales, versus the effort that is actually required by engineering. It is within this scenario that you will often hear people saying you should "under promise and over deliver", which is generally good advice.

As an agile guy, I dislike this entire model however, as it feels like waterfall to me. A huge project that is estimated at 1,000 days, a made up number which is then divided by how many engineers available, will produce a date some months in the future that is also made up. It has the veneer of science because numbers are being produced, but in reality it's made up.

In the next sections, I will explain why these numbers are unreliable, and suggest a better approach at the end. So let's get started.

Most of us are bad at estimates

Human beings are terrible at accurately estimating the time required to carry out work, even for tasks that they carry out on a regular basis. So in the software industry, why do we waste so much time and effort trying to estimate projects?

As an experiment, think about something you do every day like taking a shower. Now write down how many minutes you think it takes, and the next time you take a shower, actually time yourself using a stopwatch and spot the difference. I'd wager you spent a lot more time showering than you actually think.

The reason for this estimating blind spot is simple: most people, or at least those that work in the software industry that I have met, are generally optimistic and therefore tend to underestimate how long it takes to do things.

The tendency is to overestimate our skills, and underestimate the challenges. Meanwhile, contingency planning is often neglected.

We therefore unfairly appear to be consistently late when our project estimates don't reflect the reality of the outcomes.

Multiple all estimates by pi

One of my previous managers used to say to me:

"John, I multiple all estimates you give to me by pi"

That is pi the number 3.141… etc to infinity.

He was joking of course, but the serious point he was making was that as an experienced engineering leader, he assumed that the estimates coming from his engineers, myself in this instance, were optimistic and needed to be padded by an arbitrary amount before he was willing to share them with the wider organization, or with customers.

The 3x factor provided by pi is too aggressive, but I would advocate as a rule of thumb added 10-20% on top of estimates for unknown issues, depending on the complexity of the project.

Let’s talk about complexity next, and how that is a major factor in estimating.

Estimate complexity instead of effort

In the scrum methodology, a lot of thought has been given to the problem of estimates. Many scrum practitioners, myself included, advocate estimating tasks in story points instead of time estimates.

A lot of people get confused about points, so the way I like to explain it is points are an estimate of complexity and risk, rather than effort. People will often disagree on effort estimates, and as a result get them wrong, but its easier to get them aligned on complexity.

Therefore, complex tasks with a high degree of uncertainty receive high story points during team planning sessions, while simple tasks receive low points. The key point is that when you see a high-point task, you should think "oh that must be complex" rather than "oh that will take forever".

Story points were an attempt by scrum practitioners, with very mixed results in real project implementations, to remove the politics from estimates, especially external interference.

As an engineer, many times during my career I gave high estimates, only to have a Sales or Presales colleague tell me "that's too high, I can't sell that, try again". So being a young engineer eager to please, I reduced my estimates, only to be told "why are you late?" when the delivery date came close to matching my original estimate.

For an engineer stuck in this situation, it's a lose/lose situation, and you as their manager need to provide them with the air cover that they need just to get on with their job.

Burndowns

The sprint burndown chart is another tool from the scrum methodology that I find useful. That chart presents the amount of planned work that the team has "burned through", and in theory it should reduce, or "burn down", to zero by the end of the sprint.

In reality that rarely happens, because again people are poor at estimating, but it's still useful as it gives the teams some idea of their velocity each sprint, namely the amount of work they can reliably complete on time.

If the team hit’s 80% completion this sprint rather than 100% for example, then they will know that they brought too much work into the current sprint (due to optimistic estimates), and should reduce their intake next sprint.

After several sprint iterations, the team will get better at this.

Eat the cake

As a thought experiment, picture the following scenario:

You are standing beside an enormous cake, that is taller than you and curves over the horizon to the left and right. From where you stand, you cannot see the whole cake, and can only guess at it's size based on it's height and curvature. What should you do next, spend time trying to estimate the size of the cake, or just start eating?

The cake represents your project scope, and the longer you spend trying to figure out how big it is, the more you delay actually starting. Agile methodologies tell us that it is okay to start a project without all of the information required to complete it (unlike waterfall), but yet somehow I still find organizations stressing to estimate a whole project even when they can't see the far side of the cake, which is at best an optimistic guess. So why bother?

Wrap-up:

Lets recap what we have covered today:

1. I presented my arguments that as estimates are unreliable, we should reduce our emphasis on producing them, as they are not scientific.
2. Estimates are generally used for commercial reasons, for example for estimating project costs and delivery dates. But they have little value from an engineering perspective, due to being inaccurate.
3. Therefore, stakeholders for these estimates are all on the business side, not on the engineering side.
4. Project estimates have the veneer of science because numbers are being produced, but in reality they are made up, and you will often hear engineers use the term "guestimate" to reflect that uncertainty.
5. Human beings are terrible at accurately estimating the time required to carry out work, even for tasks that they carry out on a regular basis.
6. As estimates are produced by humans, and there is no algorithm to reliable produce them, they are nothing more that intuition.
7. The tendency is to overestimate our skills, and underestimate the challenges. Meanwhile, contingency planning is often neglected.
8. An experienced engineering leader will pad estimates provided by their team, as they will understand this inherent weakness in estimates provided by people.
9. In scrum, the shift to story points instead of day effort can help the team to focus on estimating complexity rather than effort. That is useful, because now the project estimates represent risk of uncertainty rather than effort, which is easier to estimate.
10. Sprint burndown charts, used in the scrum methodology, are a useful tool for teams to determine their velocity. If their velocity is lower than expected, they should bring less work into the next sprint. If it is higher, they should bring more.
11. Ultimately, it’s better to start a project now, rather than waiting to have perfect estimates of every task, which is impossible anyway. The fallacy of the waterfall methodology is build on perfect estimates, while agile methodologies are based on starting now, and iterating via sprints.
12. If you have an enormous cake to consume, don’t waste time trying to estimate it, instead just start eating!

I hope you enjoyed this episode, and I look forward to covering the next topic in this series with you! In the interim if you want to follow me online, you can find my blog at TechLeader.pro, or follow me on Twitter @TechLeaderPro.

Thanks for your time, take care and have a great week!

References

[1] : My original 2016 blog post on "Project estimates are useless" - https://techleader.pro/a/484-Project-estimates-are-useless

Download

techleaderpro-episode-20.mp3

File details: 16.5 MB MP3, 11 mins 27 secs duration.

Title music is "Still Cold" by Crystal Shards, licensed via www.epidemicsound.com

Subscribe

Apple Podcasts (iTunes)

Spotify

Google Podcasts

Amazon Music

YouTube

Main RSS feed

Sponsor

Five.Today is a highly-secure personal productivity application designed to help you to manage your priorities more effectively, by focusing on your five most important tasks you need to achieve each day.

Our goal is to help you to keep track of all your tasks, notes and journals in one beautifully simple place, which is highly secure via end-to-end encryption. Visit the URL Five.Today to sign up for free!