The Time Estimation Trap

Relatively Speaking

It’s a bug not a feature

You know it’s been a solid twenty-three years since the Agile Manifesto was signed when you start feeling like the grandparent at the party who remembers “the good ol’ days.” Yep, the schisms and misunderstanding in the agile community are real, and I often find myself thinking, "Why am I still teaching teams to estimate?" After all this time, you’d think we’d have moved on to more meaningful things.

Then, I made the mistake of scrolling through LinkedIn and spotted an article about story points and estimating stories. Cue my instant irritation. The topic has moved so far from anything useful that it feels like debating how many sprinkles belong on a single cupcake. Let’s face it—striving to achieve accurate time estimates in today’s hectic, ever-changing world is becoming obsolete. By the time we’ve fussed over precision estimates, the company might well be out of business.

How Did We Get Here?

So there I was, pondering how we got tangled up in this never-ending estimation loop, when a surge of unexpected rage struck—aimed squarely at the tools we use. How is it that I can avoid estimating in time, yet I still see so many teams stuck using hours in their estimates? Why should they even have to go through this level of estimation before moving up to relative estimation?

Now, I’ve long since given up the dream of finding “the perfect agile tool.” Back in the day, I spent way too many hours evaluating features, metrics, and configurations, but I’m glad to say I’ve moved past that. I’m officially tool agnostic these days. But there’s one feature I genuinely wish had never been created, and I blame the good people at Atlassian for this one: the ability to estimate stories using time.

When did this travesty happen? Why did anyone think it was a good idea? And please, is it too late to hit the undo button?

The Trap of Time Tracking in Agile

Now, let’s talk about why this is so irksome. Time tracking as part of an agile workflow is like throwing a wrench into a perfectly tuned machine. Culturally, it sets up an odd expectation that “time” can somehow accurately represent effort and complexity. It fosters mistrust (“Why did that take so long?”), encourages micromanagement, and makes estimation feel like a performance metric rather than a team tool. And let’s be real—it doesn’t make your ability to achieve your estimate any better.

Story points were meant to help us think relatively: “How big is this task compared to others?” Absolute estimation for humans is tough; just try it yourself. Estimate how long it would take you to clean every inch of your house top to bottom. You might get an educated guess if you clean regularly, but I bet it wouldn’t be spot-on. Now, estimate how long it would take to paint every room. Getting shaky, right? But if you paint one room or even one wall, you suddenly have a reference point for estimating the whole job. That’s the power of relative estimation.

The Little Compromise That Caused Big Problems

Allowing “time” into our agile estimation tools was a tiny compromise with big consequences. Once you start down that road, you risk opening the door to other, more damaging compromises: “Why should we all plan together? It’s faster if we just leave it to a leader!” Or, “Why not skip retrospectives since we don’t have time?” And, like a crack in the foundation, each tiny deviation makes it easier for the house to fall apart.

So, what’s the lesson here? Simple: Just because something seems trivial doesn’t mean it is. Compromises often end up shaping culture—and not always for the better.

Know any other “small” compromises in your ways of working that led to total disaster? I’d love to hear about them! And if you’re ready to dust off the practices that help teams truly perform, give us a shout at ReBoot Co. We’re here to reboot your delivery approach and accelerate your speed to market.