Why Time Units Beat Story Points Every Time

March 2025

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.

Why time units beat story points

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

Hiring Startup Engineers: a field manual

Hiring engineers is the most important part of building your startup. It requires significant attention and a systematic approach. A good process combined with clear evaluation criteria will set you up for success.

This field manual covers the essential aspects of hiring your first few crucial engineering roles.

Read more

Always Be Unblocking

The most impactful engineers I know do not just write code. They remove obstacles for others.

Your impact is not measured by the code you write. It is measured by how much faster your entire team moves because of you. At Cherrypick, we call this “always be unblocking” and it has become one of our core values.

Always be unblocking

Read more

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 more

Founder mode is emergency surgery

“Founder mode” is emergency surgery. It is not the right way to run a healthy business.

If your company is sick, you need to fix it. That means courageous decisions only you can make. You will need to dive in and operate sometimes. That doesn’t mean you create bottlenecks by deciding everything for years to come.

Read more

How to Build a Robust LLM Application

Meal Generator

Last month at Cherrypick we launched a brand new meal generator that uses LLMs to create personalized meal plans.

It has been a great success and we are pleased with the results. Customers are changing their plans 30% less and using their plans in their baskets 14% more.

However, getting to this point was not straightforward, and we learned many things that can go wrong when building these types of systems.

Here is what we learned about building an LLM-based product that actually works, and ends up in production rather than languishing in an investor deck as a cool tech demo.

Read more