Hours vs. Sizes vs. Counts

Humans are bad at estimating absolute time, and engineers are no exception. Research on the planning fallacy — the systematic tendency to underestimate how long tasks will take — consistently shows that people underestimate by a factor of 2 to 4, even for tasks they've done before. The problem isn't laziness or incompetence. The problem is cognitive: when you imagine doing a task, you imagine the happy path. You don't imagine the flaky test suite, the unclear acceptance criteria, the dependency that was updated last week, or the two hours you'll spend in meetings.

Hours also invite anchoring bias. Once someone says "that's probably about 4 hours," every subsequent estimate orbits around 4. If the first person had said 12, the group would have converged on a different number — not because the work changed, but because the anchor changed. Hours feel precise in a way that invites false confidence. "This is a 6-hour task" sounds like a fact. It's a guess wearing a lab coat.

The fix isn't to "get better at estimating hours." Decades of evidence say that doesn't work. The fix is to stop using a unit of measurement that triggers the planning fallacy in the first place and switch to something relative.

Relative estimation sidesteps the planning fallacy by asking "how big is this compared to something we've already done?" instead of "how many hours will this take?" You're not predicting the future — you're comparing.

The most common scales are T-shirt sizes (S, M, L, XL) and Fibonacci-style numbers (1, 2, 3, 5, 8, 13). Both work because they're deliberately imprecise. There's no meaningful difference between a 6 and a 7, so the scale doesn't offer those options. Fibonacci forces you into buckets, and the gaps between buckets grow as the numbers get larger — which matches reality. The difference between a 1 and a 2 is meaningful. The difference between a 13 and a 15 is noise.

The key to making relative estimation work is reference stories. Pick two or three completed tickets that the whole team remembers and assign them sizes: "the login page redesign was a 5, the CSV export fix was a 2, the payment integration was a 13." Now every new ticket gets compared to those references, not to an abstract time scale. "Is this more like the CSV fix or more like the login redesign?" is a question engineers can answer with confidence. "How many hours will this take?" is a question they'll get wrong.

The simplest estimation method is no estimation at all — just count tickets. If your team completes about 12 tickets per sprint, and the backlog has 15 tickets in the next sprint, you know you're overloaded without estimating a single one.

Counting works when tickets are roughly the same size, which means it works when teams are disciplined about slicing. A ticket that says "build the entire notification system" and a ticket that says "add a null check to the export endpoint" are not comparable units. But a team that consistently writes tickets sized at half a day to two days of work — where the biggest ticket is at most 3–4 times the smallest — can use ticket count as a reliable proxy for capacity.

The discipline this requires is story slicing: breaking work into pieces small enough that size variation is low. That's not free. But it has a side benefit that may be more valuable than the estimation itself — small, well-defined tickets are easier to review, easier to test, and less likely to sit "in progress" for a week. The estimation method rewards the exact behavior you want from the team anyway.