Why are Software Folks Bad at Estimates?
Hint: They are not!
We’ve all been there. You make a guess, and then you are held accountable for not guessing right.
Estimate is not a promise!
An estimate is your best prediction based on the current knowledge of the situation at the time the estimate is given, assuming you devote all your time and focus to the estimated task.
If you as a project manager treat estimate as a hard deadline without taking into account other aspects, then you probably don't understand the complexity of the domain (hidden requirements, unknown unknowns) or the volatility of the environment (incidents, meetings, emails) you are in.
Of course, we can expect that developers will take into account the degree of complexity and volatility when they provide the estimate. They actually do. But the thing is, it will hardly ever be precise anyway. Read on.
Precise estimates are possible, but…
Creating a landing page with predefined design guidelines and adding a lead collection form can most likely be estimated precisely, because it’s a simple and well-known domain for many professional front-end developers on the market.
Writing a script to transform data from one well-defined data source to another well-defined data storage (given that the data models match) can be estimated precisely, because there are plenty of data engineers on the market who have done that many times.
A web application with dozens of screens and custom logic can never be estimated precisely. Yes, we can plan and dissect the tasks, but it will never be precise simply because:
requirements will add up
scope will change
people will join and leave
new knowledge will be discovered on the way
market will change
“Walking on water and developing software from a specification are easy if both are frozen.”
— Edward Berard
In fact, this is similar to other domains.
A car service can give you a precise estimate for changing a tire, provided they have one (or usually a pair) in stock. It’s a simple, well-defined task. They have experience, and they know how to do it.
A car service can only give you a guess when you report 'something is clunking when the steering wheel is turned left.' Most likely, this will only be a timebox that allows them to find more information, but it will hardly be enough to solve the actual problem.
A car service can hardly give you any estimate if they have 50 customers with different problems knocking on their door at the same time.
The prerequisites for a precise estimate are:
Accumulated experience with the specific task type
Clear and well-defined requirements
A stable and predictable implementation environment
Those are almost never guaranteed.
Complexity is, well… complex
Quite rarely do you see the full picture. In software development and operations, there are tasks that can be estimated precisely, but in many (if not most) cases, you'll miss that one dependency, hidden requirement, or underestimate the complexity.
Humans are optimists. That might be the reason we tackle complex tasks without having all the data. We explore the task domain. Exploration leads to new knowledge and more questions.
Quite often in software, we are not just changing a tire but designing a new custom engine that meets the customer's requirements.
Of course, the software world is becoming more industrialized. We have more platforms and frameworks and define more standards. This makes us faster, but it does not eliminate the ‘unknown unknowns’ that we face daily.
Simple tasks take time
Have you ever been asked, 'Is it difficult to implement this?' The expected answer is binary: 'yes' or 'no.' But in reality, the person is actually questioning the speed of implementation. If it’s not difficult, then you can probably do it quickly, right?
The twist is that simple tasks take time. If someone tells you a task is simple, it does not mean the task can be done in five minutes. Complexity or simplicity does not directly correlate with time consumption. 'Simple' means that it's all clear and everything is known to implement it, but it can still take three days. It can also delay other 'simple' tasks in the pipeline.
Context switching is not free
Quite often, we exist in many contexts at the same time:
project A
annual meeting B
strategic initiative C
research D
family problem E
The more contexts task implementor is in, the more likely they will lose time going between different contexts. Focus is important for faster task completion. If focus is not given, then expect estimates to grow. Naturally.
The other problem with frequent context switching is that your brain loses ability to do deep work, because it prepares you for the next switch.
This constant state of readiness for change hinders implementor’s capacity to dive deeply into any single task, leading to superficial engagement rather than thorough understanding and completion.
As a result, tasks that require intense focus suffer, impacting the quality of your work. Over time, this can erode your skills in critical thinking and problem-solving, making it harder to achieve a state of flow where productivity and creativity peak.
To improve the likelihood of meeting the estimate, you must care about the implementation environment and reduce context switching as much as possible.
Should we drop using estimates altogether?
You may have seen reports stating that '70% of software projects fail.' They went over budget and were not delivered on schedule.
The thing is, it's the same with construction projects. Have you ever heard of a bridge or public building being completed on time and within budget? Good luck finding one.
Some believe we should adopt the #NoEstimates approach, at least in software development, because we are rarely right about those estimates.
On the other hand, you can’t really give infinite money and time to implement something. It will be not sustainable for the business.
So, what should we do?
“Plans are useless but planning is indispensable.”
— Dwight D. Eisenhower
I believe we should continue estimating tasks, but we must recognize that the precision of these estimates can be significantly affected by factors beyond the professionalism or experience of the software team.
Software development is often an act of exploration. We know how much it will take to reach the mountain, but we have only a vague idea what’s on the other side.
Here are some key points to consider:
Estimates vs. Commitments: Never treat an estimate as a commitment unless the task is exceptionally simple or well-known.
Task Complexity: Always consider the complexity of the task domain. Higher complexity, lower precision.
Research Time: Acknowledge that research (or more accurate estimation) is a task that requires its own time allocation. The more time you spend researching, the more precise the estimate will be. But sometimes (or actually quite often) it is better to go into the exploration/implementation mode and get results faster.
Task Outcome: Precise estimate is never the target. Value that customer gets is the target. Always search for the shortest path to that value.
Time Boxing: Professional software development team can deliver value daily/weekly/monthly. Focus on what’s achievable within the time box.
Continuous Plan Refinement: Plans are not set in stone. They change. Every time box/iteration will bring adjustments.
Task Breakdown: Always dissect tasks into smaller, more manageable units.
Implementation Environment: Minimize context switching. Reduce time spent on wasteful activities. Aggressively remove unnecessary tasks from your backlog.
Building Trust: Foster a strong trust relationship between the customer and the software folks.
Transparency: Be transparent about progress and any impediments that arise.
Good luck with your projects!