Precise Estimates: Myth or Reality?
Project Manager at JetRockets
We planned. We tried. And we failed.
Whenever our client asks, "How many hours will this feature take?" I always think:
“If I were paid a dollar for every time I get asked this, I'd have a startup explaining why an exact estimate is impossible.”
“If I were paid a dollar for every time I get asked this, I'd have a startup explaining why an exact estimate is impossible.”
But no startup yet. And the thought remains: no one knows for sure. And that’s okay.
When I first started in project management, I didn’t believe this. I was sure: everything could be calculated, everything could be anticipated, everything could be controlled. I’d tell the team: “We can handle this; we just need the right method.” I believed in a system that could be mastered through logic. But over time, I came to realize:
Accurate estimates are a myth — one that’s easy to believe in, but a myth nonetheless.
Now, I’ll share how we came to this understanding, what we tried, what went wrong — and how JetRockets handles estimates today.
What We Tried: Our Attempts to Be Accurate
Method #1: Breaking Tasks into Subtasks
"If you break everything down, there won’t be mistakes in the estimates!"
- Spoiler: False.
Breaking tasks down is useful. It makes software development more transparent and helps the team avoid getting lost in abstraction. But even the tiniest subtask can hide some technical challenges: old code, an unstable API, or a technical nuance no one noticed during the planning phase.
Method #2: Getting the Whole Team Involved in Estimates
"If everyone agrees on the call, then we’ve covered everything!"
- Yeah, right (No).
We’d gather the team, discuss the task, look at the code, and share approaches. This definitely improves the quality of the estimation and supports collaborative development, but it doesn’t guarantee perfect results. Why? Everyone has different experiences and perspectives, so what seems easy to one may be tricky for another. So, while joint estimation is useful, expecting mathematical precision is a bit optimistic (especially when building custom software solutions for non-tech founders, whose initial expectations can shift as they better understand what’s possible.)
- Yeah, right (No).
We’d gather the team, discuss the task, look at the code, and share approaches. This definitely improves the quality of the estimation and supports collaborative development, but it doesn’t guarantee perfect results. Why? Everyone has different experiences and perspectives, so what seems easy to one may be tricky for another. So, while joint estimation is useful, expecting mathematical precision is a bit optimistic (especially when building custom software solutions for non-tech founders, whose initial expectations can shift as they better understand what’s possible.)
Method #3: Using Past Tasks as References
"Last time, we did something like this in 16 hours, so it should be the same..."
- Nice try, but no.
- Nice try, but no.
Past experience is a great starting point. But even with similar functionality, the codebase, team members, architecture, external dependencies, and just the team's workload can be different. We still use references — more as a guideline, not a strict template, particularly in dynamic environments like agile software development.
Method #4: Allocating Research Time in Sprints
"If we research the code and risks in advance, there won’t be any surprises!"
- Well, fewer, but not zero.
Research requires strong technical expertise and helps reduce the unknowns, but it can’t catch everything. Even after a thorough review, there are always small details that pop up once the coding starts.
- Well, fewer, but not zero.
Research requires strong technical expertise and helps reduce the unknowns, but it can’t catch everything. Even after a thorough review, there are always small details that pop up once the coding starts.
Method #5: Rechecking Estimates Before Starting
"Let’s give an initial estimate, and then refine it before starting — it’ll be more accurate!"
- Sometimes yes.
- Sometimes yes.
After sprint planning, we’d set aside time for developers to review tasks, check the code, and adjust estimates. This is a helpful practice — it increases engagement and improves development workflow. But even with this approach, the final time can still differ from the original plan.
The Conclusion? All of these methods work — each one adds awareness, depth, and understanding to the development process. But none guarantees 100% accuracy.
Why Precise Estimates Aren’t Possible
It seems like you should be able to take a task, an experienced team, and come up with an exact timeline. But here’s why that’s not the case:
-
Programming Is Research
Even familiar tasks reveal themselves in new ways each time. The code changes, the team changes, the context changes. You can’t just "do it like last time." -
One Acceptance Criteria, Different Realities
Two similar tasks might end up being completely different in practice. It all depends on architecture, depth of development, and hidden nuances. Sometimes "just adding a checkbox" turns into an entire day of dependency analysis. -
The Human Factor
We’re all human: sometimes there’s fatigue, distractions, lack of sleep, or overload. And that’s normal. It directly affects estimates, whether we like it or not. -
Communication Doesn’t Always Come Across Perfectly
You can spend hours discussing a task and then realize everyone understood it differently. And requirements often change during the process. And that’s okay, too. -
Technical Debt Is Real
What appears to be a quick task can be significantly delayed by underlying old code and unforeseen dependencies even in high-quality software. The deeper you dive, the more details emerge.
A Simple Real-Life Example
How long does it take to get to the office?
Sounds simple, but… traffic jams, road repairs, forgetting your phone at home, a bus delay — and suddenly, everything is different.
It’s the same with tasks: everything depends on a multitude of small details that you just can’t predict ahead of time.
It’s the same with tasks: everything depends on a multitude of small details that you just can’t predict ahead of time.
What Works Better: The Alternatives That Saved Us
-
Ranges Instead of Exact Numbers
We gave up on hard numbers and now use T-shirt sizes to indicate how long a task will take: S (≤10 hours); M (11-25 hours); L (26-50 hours); and so on.
This reduces tension in the team because no one is trying to hit an exact number that will end up being an approximation anyway. -
Focus on Value, Not Numbers
For us, it’s not just about finishing the task on time —it’s about ensuring code quality and delivering scalable software. If we realize we need more time, we’re upfront with the partner and ask for an extension. This lets us focus on the result, rather than the "number," which may not reflect the real complexity of the work. -
Communication Every Step of the Way
We realized that timely and open communication is key. Developers share progress daily during meetings or in slack-channels. If a task goes beyond the original estimate, the partner gets updated information right away. This helps avoid misunderstandings and builds a strong relationship with your technology partner.
What we’ve learned for sure
Teams that can adapt win. The rest just write reports about their failures.
At JetRockets, we’ve chosen the path of transparency over precision, trust over control. And when something goes wrong, we accept it, learn from it, and move forward, all while continuing to build successful software products. If you also think it’s time to leave exact estimates behind and focus on quality, then you’re on the same page as JetRockets. If you’d like to talk about your own experience, we’re always up for a conversation!
