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.
More articles
How To Get Clarity With a New Tech Team
You have just taken over a new tech team. There is pressure to deliver, not much signal, and everything feels urgent. Perhaps the roadmap is packed. Perhaps the team seems busy. But is anything really working?
This is your field manual. If you are overwhelmed and trying to get clarity, start here.
Read moreYour Code Is A Liability
Every chunk of code you commit is more for someone else to read, digest and understand.
Every complex “clever” expression requires another few minutes of effort for each of your team. They must now interpret what you wrote and why you wrote it.
Every line you add limits your project’s responsiveness to change.
Your code is a liability. Never forget this.
Read moreHow To Avoid Bad Startup Culture
If you are not paying attention to your startup culture, I have news for you: you are already building a culture into your company. Chances are that is not the culture you want.
Every company has a culture. It is a summation of all the habits and practices that make up the work. It is every choice, good or bad, made by every person involved. Every action sets a precedent, a “how we do things here.”
This is how we are wired. We are naturally social beings and are strongly predisposed to fit in to the group we find ourselves in, and to emulate their behaviour. This reinforces culture further, and compounds when more people are involved.
A culture grows like plants in a garden. You cannot stop the life from growing, but you can decide how and where it grows. Left unattended, weeds will grow alongside the flowers. The key is recognising this and putting in the work to shape it.
Here is a quick primer on how to do the minimum to avoid bad culture, and how to get good culture going with a little attention every so often.
Read more