Stop Estimating. Start Shipping.

If you've worked in software engineering for a while, you've probably experienced the pain of work estimation. Planning poker, story points, t-shirt sizes - whatever flavor your team uses, one thing is consistent: we're almost always wrong. And even if our estimate happens to be spot-on, it might just be a case of Parkinson's Law at play - work tends to expand to fill the time available.

And that's not a personal failing. It's the nature of complex work. Software engineering is full of unknowns, changing requirements, and unpredictable edge cases. Trying to put a precise number on how long something will take is often little more than educated guesswork - and in most cases, it's more guess than educated.

So why do we keep doing it?

For many teams, estimations are used as a planning tool for roadmaps, resource allocation, or stakeholder communication. But if we're being honest, how often do those carefully estimated timelines hold up? How often does the time spent refining estimates actually deliver a return on investment?

Here's a personal red flag for me: when management starts asking, “When is this project going to be done?” and teams scramble to estimate work that stretches far into the future. That's when things get dangerous. The further ahead you estimate, the more cumulative estimation error builds up - and by the time you're a few months out, you might as well be throwing darts in the dark.

In my opinion, estimating beyond a few sprints isn't just risky - it's misleading. Instead, I like to keep things grounded and relative. I prefer using t-shirt sizes and asking simple, intuitive questions: Is this something we can ship in a day? A week? A sprint? If it's more than that, it probably needs to be broken down.

Sometimes, that means introducing MoSCoW prioritization - Must-haves, Should-haves, Could-haves, and Won't-haves - to make sure we're clear about what really matters. It's a gentle way to acknowledge that some things may fall off the edge, and that's okay. It's better to be realistic than overly optimistic.

That's not to say estimation is entirely useless. In my experience, the best thing about estimating is that it surfaces vague or oversized tasks. If a story feels huge, that's a signal - not a prediction. Estimation, in that sense, is less about accuracy and more about prompting better conversations and decomposition.

So maybe we should stop treating estimation as a forecast, and instead, use it as a flashlight - something to help us see where we need more clarity, not where we'll be in three months.

Less time estimating, more time building. That's where the real value lies.