Why Time Units Beat Story Points Every Time

Story points, t-shirt sizes, and fibonacci numbers. We have created an entire vocabulary to avoid saying what we actually mean. The truth is simpler: we should just use time units.

This realisation emerged from years of watching teams struggle with abstract estimation systems. The solution was right in front of us all along.

The Problem with Points

Story points promise to free us from the burden of time estimation. They offer a theoretical framework for measuring complexity and effort without committing to specific timeframes.

The reality proves different. Product owners immediately ask what a point means in days. Stakeholders create spreadsheets converting points to hours. We end up doing time estimation anyway, just with extra steps and confusion.

Why Time Units Work Better

When a developer says “months” instead of “weeks,” they communicate something important about uncertainty. The unit itself carries meaning. No translation required.

Every stakeholder understands what a week means. No one needs help to grasp that “hours” signals a smaller task while “months” indicates a major undertaking.

Natural Precision Levels

Time units provide built-in granularity:

• Seconds or minutes for the most precise estimates
• Hours or days for moderate uncertainty
• Weeks or months for significant uncertainty

This natural progression maps perfectly to how humans think about future work. We know tomorrow with reasonable certainty. Next month holds more unknowns.

The Stakeholder Perspective

Product owners receive clearer signals. “This will take months” communicates more truth than “this is an XXL story.” The broader the time unit, the more uncertainty it admits. The granularity of tracking matches the confidence of the estimate.

Tasks estimated in months do not need daily updates, but also should not be started yet. They need breaking down into smaller chunks.

Making The Switch

Moving to time units requires minimal process change. Simply replace your existing estimation scale with:

• Seconds/Minutes: Trivial changes
• Hours: Small features
• Days: Moderate features
• Weeks: Large features
• Months: Major undertakings

The key lies in matching the unit to your confidence level. If you cannot estimate in days with reasonable certainty, use weeks.

Common Objections

Some argue that time estimates create pressure to deliver by specific dates. This misses the point. Time units communicate scale and uncertainty. “Two to three weeks” provides more honest communication than “13 story points.”

Others suggest teams will pad estimates to protect themselves. Yet this can happen with any estimation system (and you have bigger problems if it does). At least with time units we can have more direct conversations about why estimates seem large and what we can do about it.

The Path Forward

Estimation exists to facilitate communication between developers and stakeholders. Our estimation system should serve this goal above all else.

Time units provide a universal language that everyone understands. They offer natural gradients of uncertainty. They encourage honest conversations about scope and complexity.

Sometimes the best solutions are the obvious ones. We do not need elaborate systems to say what we mean.