Story Points vs Hours: How to Explain Relative Estimation to a Team That Thinks in Days

Someone in refinement asks for an estimate, and an engineer says, "About two days." The product owner writes down a 3. A sprint later, someone asks why a 3 took a week. If your team thinks in days, story points can feel like a translation layer nobody asked for.

The story points vs hours question deserves a straight answer, because the people asking it aren't being difficult. Hours are how most of us plan everything else. You can explain relative estimation in a few plain sentences and still give your product owner a date range when they ask for one.

Story points vs hours: why "how many hours?" feels natural and still misleads

Hours and days feel concrete. Stakeholders plan in calendar weeks, and "three days" sounds like something you can check later. That's also why hour estimates cause so much trouble.

An hour estimate is a guess about how fast one particular person will work. Ask a senior engineer and someone who joined last quarter how long the same story will take, and you'll often hear two very different numbers. But both can be honest. They're picturing different people doing the work.

Mountain Goat Software's guide to story points says, "When the team estimates in hours, those differences often become personal. When the team estimates in story points, the discussion can stay on the work: what makes the item larger, riskier, less certain, or more complex than another item."

You've probably seen the personal version. The newer engineer pads their number so they won't look slow, and the senior engineer's quick guess turns into everyone's deadline. Soon the conversation is about who's fast, and the story itself barely gets discussed.

It also helps to lower the bar. An estimate only has to be good enough for the decision in front of you. A product owner deciding whether a feature fits next quarter wants to know if it's a small job or a big one compared with the other options on the table.

Relative estimation in plain English

A story point is a size measured against work your team already knows. When you call a story a 5, you're saying it looks about as big as other 5s you've finished and bigger than your 3s.

TeamRetro's guide to relative vs absolute estimation says, "Relative estimation sizes a piece of work by comparing it to a reference story the team has already delivered (bigger, smaller, about the same) instead of predicting how many hours it will take." It also says, "Relative sizing is faster and holds up better, because people judge comparison well and absolute time badly."

Treat that second line as a practitioner's view. It still fits everyday life: you'd struggle to say what your bag weighs in grams, but you can tell which of two bags is heavier.

Points aren't a disguised unit of time, either. Mountain Goat's story points guide says, "Story points also are not duration. Effort and duration are related, but the team uses points to compare size." A point bundles how much there is to do with what could go wrong and what you don't know yet. That's why a small change to a fragile, untested module can earn a bigger number than a long but familiar task.

The usual choice is a scale with widening gaps, such as a Fibonacci-style deck (1, 2, 3, 5, 8, 13). The gaps grow because your confidence drops as work gets bigger. Nobody can honestly tell a 12 from a 13, so the deck doesn't offer that choice, and false precision never gets a foothold. If you haven't settled on a deck yet, there's a separate guide to choosing a point scale that fits your team.

When a stakeholder asks what a point is, you can answer in one sentence: "This story looks about as big as that one we shipped last month." A point tells you how big something is compared with work the team has done. It doesn't say who'll do it or which day it'll land.

A three-step routine: reference story, comparison, no conversion

You can try this in your next refinement session. There are three steps, and the third is the one teams break first.

Pick a reference story

Choose one or two finished stories that the whole team agrees on. Good candidates are ones most people worked on or reviewed, and that didn't blow up halfway through. Give the reference a number near the lower middle of your scale, say a 3, and it becomes the anchor for everything else.

Before your next refinement, take five minutes to choose that reference story and write down, in a sentence or two, why the team agreed on its size. The note is worth more than the number. When someone new joins, or someone says a 3 used to feel smaller, you can read the reasoning back and skip the argument from memory.

Compare each new story to it

For every new story, ask one question: is it bigger than the reference, smaller, or about the same? If it's bigger, ask whether it's a bit bigger or a lot bigger, and let the scale handle the rest.

Keep the talk on the work itself, like the edge cases or the part of the codebase nobody has touched in a year, and leave out who'll pick it up. When two people disagree on the comparison, that's useful, because it usually means one of them knows something the other doesn't.

Don't convert points to hours

Eventually someone asks, "OK, but how many hours is a point?" The room will want to give an answer. I'd hold off. Plane's article on story points vs time tracking says, "Never convert points to hours: The moment points become hours, they stop being useful."

Once a point has an exchange rate, a 5 turns into a number of days and you're back to arguing about whose days. The number starts to feel like a deadline, and people go back to padding.

When someone asks for the exchange rate, tell them the date question has an answer and that it comes from the team's history. Then go back to comparing stories.

Make the comparison visible with a planning poker round

Comparison works best when everyone makes their own call before hearing anyone else's. If the tech lead says "that's a 3" first, the rest of the room tends to drift toward 3, whatever they were thinking a moment ago.

Planning poker fixes the order. Plane's guide describes it this way: "The team discusses the story, privately picks a number, and reveals it simultaneously." It also says, "If team estimates diverge significantly, something is unclear—perhaps a missing requirement, an unknown integration, or an external dependency." If your team hasn't played yet, start with running a first planning poker session.

Say the cards come up 3, 3, 5 and 13. Don't average them and move on. Ask the person who picked 13 what they see, since they may know the change touches a service another team owns.

Then ask one of the people who picked 3. Maybe they're picturing a thinner version of the story than the one the product owner described. Once both have talked, the whole team is finally estimating the same story.

Hear the outliers first, then re-vote.

There's more on hearing outlier votes after the reveal without letting one story eat the whole session. For a team that estimates remotely, TinyTroop is free online planning poker: votes stay secret until the reveal, and when the votes split, it names the outlier votes so you know whom to hear first.

If the cards stay far apart after that discussion, the story probably isn't ready. Deciding what to do when estimates stay far apart is its own call: re-vote, split or park.

Answering "so when will it be done?"

At some point a product owner or stakeholder asks, "So when will it be done?" It's a fair question, and you can answer it without going back to hours.

Mountain Goat Software's guide says, "Use story points to estimate relative effort. Use velocity to forecast." Velocity is the number of points your team finishes per sprint, looked at across several sprints. TeamRetro's estimation guide puts dates at team level: "The right move is to translate at the team level: through velocity, not through per-story duration estimates."

In practice, look at what the team has finished over recent sprints, compare it with how much work sits ahead of the item, and give a range. Then name what could move it, such as a dependency on another team or a story near the end that's still fuzzy. If your product owner needs words for stakeholders, give them this: "Here's the range from our last sprints, and here's what could move it."

How tight that range can be depends on your team. If velocity swings a lot from sprint to sprint, the range gets wider, and saying so up front beats a tidy date that slips.

Keep the two conversations apart. Refinement is where the team compares stories, while the date conversation runs on history and ranges. Once they blur, people start hearing a 5 as a promise again.

Choose your reference story this week, compare the next few stories against it, and answer date questions from the team's history. Want to try that comparison with secret votes and a shared reveal? Start a free room and size a few stories against your new reference.