Story points. T-shirt sizing. Planning poker. Fibonacci sequences applied to software development as if writing code follows mathematical patterns.
Let's be honest about what this is: theater.
The Fundamental Problem
Estimation assumes you know what you're going to build before you build it. But the defining characteristic of knowledge work is that you don't. You discover the work by doing the work. The hard parts are never the parts you expected. The easy parts sometimes aren't.
An estimate made before the work begins is a guess. We dress it up with Fibonacci numbers and consensus-building exercises, but it's still a guess. And the meetings we hold to make that guess are time we could have spent actually doing the work.
The Real Question
There is no such thing as something that is only important if it can be done quickly. If it's important, what does it matter if it takes five minutes or five days? You're going to do it either way. If it's not important, why are you estimating it at all?
The question isn't "how long will this take?" The question is "is this worth doing?" Once you've answered that, do it. If it takes longer than expected, it takes longer. The estimate didn't change the work. It just added a meeting.
What Estimates Actually Do
Estimates serve one legitimate purpose: creating budgets for new work when you're deciding whether to invest in a project at all. "Is this a week of work or six months?" is a reasonable question when deciding whether to fund something.
Outside of that, estimates are trying to put numbers on things that resist numbering. And the meetings, the debates, the negotiation of whether something is a 3 or a 5 — these are signs you're focusing on the wrong thing.
Teams that estimate are optimizing for predictability. Teams that ship are optimizing for value. These are not the same thing.