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?
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.
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.
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.
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.
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.
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?
Lets recap what we have covered today:
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!
 : My original 2016 blog post on "Project estimates are useless" - https://techleader.pro/a/484-Project-estimates-are-useless
File details: 16.5 MB MP3, 11 mins 27 secs duration.
Title music is "Still Cold" by Crystal Shards, licensed via www.epidemicsound.com
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!