Estimate or Die
There’s one thing I can always count on from my old project manager friend: zero context. No "Hey, how's it going?" No "This reminded me of that one project we worked on." Just a random Instagram link, dropped into my DMs like a cryptic puzzle.
Curious (and slightly concerned), I tapped it.
Static. Flickering lights. A deep, rasping voice filled the room:
"Hello, team. I want to play a game."
The video shows Billy the Puppet from the Saw movie...
"We could use T-shirt sizes... but that would be too easy. Instead, we will use numbers in the Fibonacci sequence."
I laughed. Then I winced. Because while this was obviously satire, it was also painfully accurate.
See, I’ve always been a "gut estimate" kind of guy. Just throw out a number, move on, and deal with reality later. But now, I’m deep in a three-month solo dev project, where estimation isn’t about avoiding chaos—it’s just to give stakeholders a vague idea of how long this will take. The chaos is still inevitable.
And, despite my natural resistance, I’m starting to see the value. Even bad estimates are better than none. Because as much as we love to think Agile means "just start coding and figure it out later," the truth is—having some idea of what’s ahead actually helps you move faster, not slower.
It’s frustrating. It’s tedious. But, let’s be honest—so is arguing about whether something is a 5 or an 8 when we all know it’s just "more than we want to do right now."
Ouch, I feel attacked!
Now, that Instagram video wasn’t supposed to be a life lesson. It was satire—just a joke. And yet, as I sat there watching Jigsaw talk about Fibonacci-based estimation like it was a form of psychological torture, I couldn’t shake the feeling that I had been personally attacked.
Because let’s be honest—sometimes, estimation does feel like a horror movie. You sit in a meeting, trapped with your team, staring at a backlog of tickets, knowing you won’t leave until you’ve assigned a number to each one. The PMs assure you, “There are no wrong answers.” But the moment you suggest an 8 instead of a 5, the room erupts into chaos.
“Are you sure this isn’t a 5?”
“Feels like a 13 to me.”
“Hold on, let’s compare it to that other ticket from last sprint.”
And suddenly, a task that could have been done in the time spent debating is now the subject of a full-blown philosophical discussion.
The satire in that short worked because it captured a very real frustration: estimation is a weird mix of necessary planning and absolute nonsense. The numbers aren’t real in any measurable sense—there’s no scientific formula for determining whether something is a 3 or a 5. But somehow, these arbitrary figures are the foundation of sprint planning, project roadmaps, and stakeholder expectations.
It’s ridiculous. But also, against all logic… it kind of works 🤷.
Why Do We Even Bother Estimating?
A few weeks ago, I kicked off a three-month project. Just me as the solo developer, a backlog, and the expectation that, at some point, we would be able to tell the stakeholders roughly how long it would take to deliver.
Now, earlier in my career, this would have been the moment where I thought, "No problem, I’ll just get started and figure it out as I go." But experience has taught me that’s the fastest way to accidentally commit to a six-month project without realizing it.
Luckily, this time, I had a solid backlog to start with. Most of the stories were written by Em, our Product Owner, and they were detailed and clear 🤩, making them easy to estimate. I could look at them, trust my gut, and assign numbers without overthinking. It was smooth sailing—until I got to the technical stories.
That’s when things got messy.
Because when you’re working in a legacy codebase, even the simplest task can be a trap. A feature that should be a straightforward 3-pointer can quickly unravel into:
- A forgotten dependency buried in an old service,
- A function that technically works but hasn’t been touched since before COVID,
- An API that does almost what you need—except for one crucial thing that breaks everything.
And that’s when it hit me: whether it’s a feature request or a technical task, nothing is ever as simple as it seems.
That’s why we estimate—not because we expect to be 100% accurate, but because thinking ahead is better than walking in blind. And as frustrating as it can be, that little bit of foresight makes all the difference between a manageable project and a slow-motion train wreck.
The Unexpected Side Effect of Planning
Earlier in my career, I saw planning as an obstacle. I wanted to get stuff done, not sit in meetings debating whether a ticket was a 3 or a 5. Back then, estimation felt like an unnecessary roadblock—just another step between me and actually writing code.
But these days? We have a nice process. One that doesn’t feel like a waste of time, because it actually helps me see into the future.
During backlog refinement, I’m no longer just assigning arbitrary numbers—I’m mentally stepping through the work. I can picture myself doing the task, running into potential issues, and realizing where things might go off the rails. I spot dependencies before they trip me up, recognize hidden complexity, and sometimes, even catch problems before they become full-blown disasters.
It turns out, estimation isn’t just about setting expectations for others—it’s a tool for future-proofing my own sanity. And now that I see it that way, I can’t imagine working without it.
Guessing With Purpose
There was a time when I thought estimating was pointless. No matter what number you assign, things always take longer than expected, so why bother?
But now that I’ve been through enough projects, I’ve realized something: even an imperfect estimate is valuable.
The real benefit of estimation isn’t the number itself—it’s the process of thinking through the work before you start. And now that we have a solid process, estimation doesn’t feel like a chore—it feels like a preview of the work ahead.
Instead of diving in blind, I get to step back and ask:
- What’s the actual scope of this work?
- What hidden problems might I run into?
- How does this fit into the bigger picture?
It’s like getting a sneak peek of my own workload, and that alone makes it worthwhile 💪.
Estimating Without Losing Your Mind
For the longest time, I thought estimation and agility were at odds with each other. Agile is supposed to be about speed, about embracing change and iterating quickly. Meanwhile, estimation often feels like the opposite—slowing down to analyze, predict, and preemptively assign numbers to work that might shift at any moment.
But here’s the twist: good estimation doesn’t slow you down—it helps you move faster.
Think about it. When you take the time to estimate properly, you:
The trick is not to overdo it. Estimation shouldn’t turn into a bureaucratic nightmare where every task requires a 30-minute philosophical debate. It’s just about getting a rough sense of what’s ahead so you can adapt more effectively.
Because, let’s be real—Agile never meant “don’t plan.” It meant “plan just enough so you don’t completely screw yourself over.”
Estimate or Die (Figuratively, Of Course)
Looking back, I started this project with the same attitude I’ve always had toward estimation: I’ll do it if I have to, but I don’t have to like it. And while that hasn’t changed entirely, I have to admit—there’s value in this process.
Estimating work isn’t about predicting the future with perfect accuracy. It’s about getting just enough clarity to avoid walking into unnecessary disasters. It’s about spatial awareness—understanding the shape of the work ahead so you can make better choices. Whether it’s a design decision, an architectural choice, or just figuring out how painful your next sprint will be, having a rough sense of scope makes life easier.
So, while I may never love estimation, I no longer see it as pointless. And I guess that’s the real takeaway here: you don’t have to enjoy it—you just have to accept that sometimes, the numbers do matter.
Because at the end of the day, whether you like it or not… estimate, or die. (Metaphorically. Hopefully.)