Engineering Estimates: 1 week means 4
Why your estimate is a lie you keep telling yourself
When you are asked "How long will this project take?" or "How long will it take for you to do this task?" your thought usually goes something like this:
"Well, if absolutely everything goes right, and I have no blockers, and I work full time on it... I can get probably get it done in 1 week. Okay, that is way too long ... let's say 3 days. That still sounds good and I'll look good if I can deliver it on time."
And there it is, the saga of the terrible software estimates continues.
We've all been there. Massively underestimating the time and effort required for a project, only to push out the timeline again and again and again.
It's a common problem that plagues tech.
But why does this keep happening? Are we all just shit at doing basic math and project planning?
Well, it's complex.
Yeah, humans suck.
The main issue with estimates boils down to a few key cognitive biases that affect our judgment, even when we have experience that should indicate otherwise:
The Planning: We tend to underestimate how long a task will take, even when we have lots of historical data indicating otherwise. We focus on the best-case scenario rather than the average case.
The Optimism: We overestimate the probability of positive events and underestimate negative ones. We assume that surely nothing will go wrong this time! :)
The Number: We latch onto the first number put forward in the planning process, often an unrealistically low one, and then have trouble adjusting sufficiently from that starting point even when given new information.
The Dunning-Kruger Effect: The less you know about a domain, the more you tend to underestimate its complexity. This can lead to overconfidence in our ability to complete tasks quickly, without fully grasping the intricacies involved.
You can read more about the effect here:
These biases, just show that humans just suck at estimating things.
Also, we don't have the ability to see the future. Thank god for that.
What can we do ?
So what can we do?
Estimates are a necessary evil in SDLC (software development lifecycle).
We needed a shift in mindset. We need to rethink how we communicate estimates.
Risk is part of it: We need to stop pretending that we have a crystal ball that can predict the future. Estimates as ranges, not single numbers deadlines.
"This will likely take 2-4 months, with an optimistic scenario of 6 weeks if X, Y, Z."
Estimate in Effort, Not Time: I know that this might be hard in the beginning but try estimating in terms of effort or rather than dates.
"This feels like an 8-point task, which usually takes us 1-2 sprints." The problem with time estimates is that it assumes 100% capacity, which never happens in the real world.
Explain your decision: Talk about the assumptions and risks that led you into your estimates.
"This assumes we get that critical integration on time with the client's internal team. If that doesn't happen, it could push the timeline back by several weeks."
Iterate, iterate, iterate: Review estimates regularly as you gain new information. Don't forget to continuously update and communicate your new estimates to stakeholders.
Estimates are not set in stone.
Most people think like that but they really aren't.
I'm not saying that we should postpone things indefinitely.
What I'm saying is that sometimes we need to do some tradeoffs and delay or postpone something.
"It'll take longer than you want."
As important as the mindset shift is, the hardest part is often saying no to unrealistic timelines to stakeholders. Pushing back on aggressive timelines and promising less than hoped for can be uncomfortable.
There is always a positive side: "Taking the time to do this right sets us up for long term success and fewer shitstorms in the future."
Explain the tradeoffs: "We could cut corners to hit that date, but it will generate a lot of technical debt that will slow us down and create quality issues later."
Offer alternatives: "If going live in Q2 is a hard requirement, let's scope down the MVP to features that bring value and move the nice to haves to a later date."
Talk with your team: "Here's our current estimate range. What constraints and risks do you see that we should look into ? Any super priority things ?"
Show your damn work: Provide regular demos, show milestones hits, and celebrate small wins to build trust in the process.
You're not pushing back because you don't want to work.
You're pushing back because you know what it takes to make it work.
TL;DR - Estimates sucks, but we need to do them.
Estimates in software engineering will always be 50% art 50% science.
Unexpected issues appear, requirements change, and life happens.
Estimates are educated guesses.
Perfect estimates don't exist.
It's okay to be wrong (you will be).
Communication > Accuracy.
Until Next Time 😎
Got thoughts? Questions? Just want to say hi? I'm all ears! You can find me on the professional network (LinkedIn) or the digital playground (X).
I'm always up for a chat and promise to get back to everyone. After all, the best part of writing is the conversations it starts.
Great article, once again!