Estimation arguments on teams almost always come down to a misunderstanding about what an estimate is. People treat the number as a prediction of hours, and then feel betrayed when reality disagrees. The number was never that. An estimate is a single value bundling four different things at once.

The four things inside one number#

When someone puts a number on a story, they're really compressing four separate ideas into a single figure:

• Amount of work — how much there is to do.
• Complexity — how intricate or interdependent the work is.
• Knowledge — what we already understand about the problem.
• Uncertainty — what we don't yet understand.

Two stories with identical "amount of work" can deserve wildly different estimates because one is well understood and the other is a fog of unknowns. That's not estimation failing; that's estimation working as intended. The number is meant to carry all four signals.

Estimate relatively, not absolutely#

The most useful shift I ever made was to stop estimating in absolute hours and start estimating relatively. Instead of asking "how many hours will this take," I ask "how does this story compare to other stories we've already sized?" Humans are genuinely bad at predicting absolute durations and surprisingly good at comparison. We can reliably say "this is bigger than that" even when we can't say "this is fourteen hours."

A relative T-shirt scale captures this beautifully. Extra-small, small, medium, large. Each story gets placed next to known reference points rather than mapped onto a clock. The scale's vagueness is a feature: it stops everyone from pretending to a precision that doesn't exist.

The implicit time box#

Here's the subtle part that makes relative sizing actually work. When you put a story into a size bucket, you're grouping it with other stories that share a similar profile of work, complexity, and risk — you are explicitly not estimating how long it will take. And yet every story still has a real duration; you just don't know it and don't need to.

What this means is that each size category carries an implicit time box — a range of durations the team has tacitly agreed is acceptable for that size. Nobody writes the range down. Nobody could tell you the exact number. You only discover the boundary when a story blows through it: a "small" that drags on for a week announces that it was never really a small. That surprise is the signal, and it's far more useful than any up-front hour estimate, because it's grounded in what actually happened.

Some teams frame the bundle slightly differently and talk about complexity, effort, and risk as the three things a point represents — complexity being how complicated it is, effort being how much sheer work there is even when it's simple, and risk being what's hidden or not yet understood. It's the same idea wearing different labels: a point is a profile, not a clock reading.

A mental model#

The way I hold it in my head is roughly:

Estimate is a function of work, complexity, knowledge, and uncertainty, expressed relative to a known reference.

That last clause matters as much as the four inputs. An estimate with no reference point is just a guess in a vacuum. An estimate anchored to "remember that login story we called a medium" is grounded in shared lived experience.

Why absolute hours mislead#

Absolute-hour estimates fail for predictable reasons. They imply a confidence about uncertainty that nobody actually has. They invite false precision, where "sixteen hours" sounds more trustworthy than "medium" despite carrying no more real information. And they tempt managers to treat estimates as commitments, which corrodes trust the moment an unforeseeable unknown surfaces, as one always does.

Worse, absolute hours hide the four-way bundle. When a story blows past its hour estimate, you can't tell whether the work was larger, the complexity higher, the knowledge thinner, or the uncertainty deeper than expected. The number gave you nothing to learn from.

Relative sizing plus throughput#

Here's the part that surprises people: you don't need absolute estimates to forecast. Pair relative sizing with throughput — how many stories of a given size your team actually completes per week — and you can forecast delivery dates empirically. You measure what the team really does rather than predicting what you hope it might do.

This combination beats absolute estimation on its own terms. It's more honest about uncertainty, it improves as you gather more historical throughput, and it sidesteps the demoralizing ritual of debating whether something is a six or an eight in hours. Size relatively, measure throughput, and let the data tell you when things will be done. The team spends its energy understanding the work instead of defending a clock reading nobody believed in the first place.