Why is it so hard to provide accurate estimates?
And how can we developers and creators get better at it?
If there is one thing that we software developers are infamous for, it is our inability to estimate our work accurately.
The problem is so commonplace that many project managers consider it best practice to multiply developer estimates by a factor of two — at least.
Whether you are a software developer or not doesn't matter; if you have been in the vicinity of a software project, you probably know what I am talking about.
Why has it come to this? Why is the simple question "how long will it take to build this?" so hard to answer?
Apart from the fact that we are trying to predict the future, the answer is that the act of estimating is complex yet deceivingly simple, especially when we bite off more than we can chew.
The larger the task, the more prone we are to be overoptimistic. We overlook potential risks, neglect steps necessary to finish, and ignore delays incurred by others involved in the process.
And — worst of all — we tend to overestimate how much we learn from previous estimates.
Navigating a world of uncertainties
Whether we are in an agile environment or not, we typically estimate tasks in bulk during group meetings. The good thing about this is that we get multiple perspectives, but there are also drawbacks.
For instance, the amount of time available to spend on each item on the list is limited. This time constraint means that we cannot afford the luxury of leaving no stone unturned for each and every task. Instead, the process relies on gut feeling and discussion.
While these assessments (hopefully) rely on past experience, we will make subconscious assumptions. We might take certain things for granted, or we neglect to factor in all the unknowns. Yes, even if we are seniors with 25+ years of experience.
Another factor is skillset and experience variability. What if the people that end up doing the work aren't the ones providing the estimates?
What one individual perceives as easy might be less obvious for another, and team composition tends to change over time.
Then there is peer pressure. I have seen it so many times: junior developers not airing their worries out of fear of coming off as ignorant or difficult. Or people keeping their mouths shut for political reasons despite knowing that their cocksure lead developer is wrong.
In other words, biases and group psychology will inevitably affect our estimates.
We can alleviate the latter to some degree with agile techniques like planning poker and facilitated discussions, but what about the former?
The seven time prediction biases
The book Time Predictions: Understanding and Avoiding Unrealism in Project Planning and Everyday Life by Norwegian computer scientists and researchers Magne Jørgensen and Torleif Halkjelsvik dives deep into this subject. Among all the nuggets and takeaways in the book, the authors list seven biases:
1. The team scaling fallacy
A team twice as large tends to deliver less than half the output per time unit due to an increase in the need for coordination. Larger projects typically need more administration and project management than smaller projects. Hence, they often have lower productivity.
2. Anchoring effects
Anchors are things like budgets, development time expectations, and judgmental statements about how complex or simple a task is. These anchors can have a substantial impact, and the best way to avoid this effect is to limit the team's exposure to them.
3. Sequence effects
Order matters a lot more than we think. The previous prediction we make will typically influence the next. If the last task was small and the current is a medium, we tend to underestimate the medium task. And if the former task was large, we tend to overestimate the next medium task.
4. Format effects
Sometimes time is scarce, and focus lies on delivering anything at all. This is called the inverted request format, and it typically leads to over-optimistic estimates of how much we will be able to ship.
5. The magnitude effect
Huge tasks are more challenging to estimate than tiny ones. The advice "when facing uncertainty, break your problems into smaller problems" is very relevant here. And when applied, we typically end up with a total estimate that supersedes the initial overall assessment.
6. The task name length effect
Longer task names tend to increase estimates, especially in inexperienced teams. Teams with more senior developers tend to be less affected by this, but it is still a factor. Personally, I like my task names short, crisp, and to the point. We can always provide more detail in the description field.
7. The time unit effect
Predictions made in days or weeks tend to lead to higher estimates than predictions made in hours. Adapt the granularity to the size of your scope, and avoid using hours for large projects or days for minor projects.
The communication mismatch
Biases aside, there is another problem: it's often unclear what people mean when they provide an estimate.
Are they talking about calendar time or actual development time? Have they factored in meetings and other commitments?
In the agile world, the preferred unit of measure for estimating is Story Points. It is intended to be a relative measure of how complex something is, compared to a known, agreed-upon baseline.
Advocates of this method claim that estimation in story points invites collaboration and acts as a team-building activity as team members constructively share, debate, and criticize each other.
They also like to give prominence to the fact that Story Points lack a time component, which implicitly would eliminate the problem with variable individual capabilities.
I like the idea on a theoretical plane, but unfortunately, I have seen it blow up so many times. As human beings, we tend to include duration among the factors that make up perceived complexity, at least subconsciously. So why not acknowledge that?
So instead, my personal preference is Ideal Days (or hours). An ideal day is when you experience no disturbances and can focus on the task at hand. They tend to be a lot easier to grasp for teams new to agile methodology, and we can always add a separate measure for perceived complexity later on as we mature as a team.
Unfortunately, there are no perfect solutions. What constitutes an ideal day for me might be something else for you. The same goes for story points: a task that appears complex to me might be child's play for you.
So, apart from keeping our team intact for as long as possible, what can we do to improve?
The secret weapon — more feedback loops
Imagine that you have studied hard for an exam. Afterward, you receive the bad news that you failed. But what's even worse: you cannot learn more about what parts of the exam you failed at.
Without this information, it will be tough to figure out where you need to focus your efforts in studying for the retake of that exam.
Amazingly enough, this is not far from the reality of many teams out there, with an ironic twist: they have put themselves in that situation by ignoring potential feedback loops.
Sure, gut feeling and collective memory go a long way, but why not acknowledge the fact that there is safety in numbers?
Revisit old estimates. Discuss similarities and differences between previous tasks and the ones at hand. Use your task management system and look at the actual numbers.
But that's not all. There is actually one more tactic we could employ: loop in your time reports as well.
With detailed time tracking, we would not only have past estimates to guide us — we would have the factual durations for each and every stage of development of every task.
Without feedback loops, we don't know much more than "we missed the mark" or "we succeeded."
But armed with time entries and previous estimates, we can tell exactly how well we did.
Use feedback loops. And especially time tracking.
Takeaways
Regardless of how much our stakeholders want to, our estimates should never be treated like commitments. After all, we are trying to predict the future.
That said — our estimation capability is just like any other skill: the more we practice, the better we become. Just don't forget to keep track of the outcomes.
So — always strive to break problems into more manageable parts. You will be amazed by how often 2 + 2 > 4.
Avoid biases by keeping them top of mind in your estimation sessions, and prevent the effects of peer pressure by using facilitated voting and discussion.
And — again — utilize time tracking. If you are working in software development or at an agency, you're probably obliged to account for where you spend your hours already.
So — why not let that information benefit yourself and your team? Let time tracking become the feedback loop that takes your team's estimation game to the next level.
Happy estimating!