Story Points vs Hours: How to Estimate Agile Work

Every new agile team asks the same question in the first month. "Why are we using story points? Can't we just say how many hours it'll take?" It's a fair thing to ask. Hours feel concrete, and points feel like a made up currency that somebody invented to confuse managers.

Here's the honest answer. Both have a place. This guide explains what story points actually measure, why many teams prefer them to hours, when hours still make sense, and how a planning poker session works, so you can try it with your own team this week.

What are story points?

Story points are a unit for estimating how big a piece of work is compared with other pieces of work. They bundle three things into one number: how much work there is, how complicated it is, and how much you don't yet know. A story worth 5 points isn't "five hours." It's roughly bigger than a 3 and smaller than an 8.

Most teams pick numbers from a modified Fibonacci sequence, like 1, 2, 3, 5, 8 and 13. The gaps grow as the numbers rise, which is the point. The bigger a thing is, the less accurately you can estimate it, so the scale stops pretending you can tell 12 from 13.

Why teams use story points instead of hours

People are better at comparing than predicting

Ask someone how long a task will take and you'll get a hopeful guess. Ask them whether it's bigger or smaller than the login page they built last month, and you'll get a sensible answer in seconds.

Points don't depend on who does the work

A task might take a senior developer three hours and a new joiner nine. In hours, you have to argue about whose hours count. In points, the story is a 3 whoever picks it up.

They stop the estimate becoming a promise

An estimate of eight hours gets treated as a deadline. A 5 point story is clearly a rough size, which lowers the temptation to blame someone when reality differs.

They feed velocity

Add up the points of finished stories each sprint and you have velocity, a simple way to forecast how much the team can take on. If you're new to the term, the agile glossary pt.3 (iteration, velocity, user story) explains it in plain words.

Story points vs hours at a glance

When hours still make sense

• Tasks inside a story, when you want a quick sense of the day's work

• Fixed price or time based client contracts that bill by the hour

• Very small or routine work, like a config change you've done twenty times

• Checking team capacity, such as how many working hours are free this sprint

Plenty of teams mix them. Points for stories, hours for the little tasks under each story, and capacity in hours for the sprint. Nobody gets arrested for that.

How to set up your first scale

Start with a reference story. Pick something the team has built recently, that everyone remembers, and agree it's a 3. Maybe a simple form with validation and a save button. Everything else gets compared with it.

Then find a small one and call it a 1, and a big one and call it an 8. Now you've got three anchors. When a new story comes up, the question is simple: is it more like the 1, the 3 or the 8?

How planning poker works

Planning poker is the most common way to estimate points as a group, and it's meant to stop the loudest person setting the number. If you want to see where this style of estimating came from, take a look at the Extreme Programming Planning Game, which put the idea of customers choosing scope and developers estimating it on the map.

Step by step

• The product owner reads the story and answers questions

• Each person privately picks a card with their estimate

• Everyone reveals at the same time

• If the numbers match, you're done

• If they differ, the highest and the lowest explain their thinking

• Estimate again, usually once or twice, until the team agrees

Most of the value is in the conversation after the reveal. A 2 next to a 13 means two people understand the story very differently, and it's far better to find that out now than in the middle of the sprint.

A quick example of sizing a real story

Say the team has agreed that the simple contact form is a 3. Now a new story arrives: "As a customer, I want to reset my password by email." Is it bigger than the form? A bit. There's an email to send, a secure link to generate and an expiry to handle, so most people say 5.

Then someone says, "We've never sent emails from this system." That's uncertainty, and it moves the vote to 8. Notice how the conversation, not the number, is what's valuable. The team just found a hidden risk in ninety seconds.

What to do with unknowns

When a story is full of unknowns, run a short research task first, often called a spike. Give it a time limit, like one day, and let it produce an answer instead of working code. Then size the real story with what you've learned.

What if the team can't agree?

It happens, and it's usually healthy. If the second round of voting is still split, don't average the numbers. Ask what each person is assuming, write the assumptions on the story and go with the higher number or split the story. Spending more than five minutes on one story is a sign it needs more detail, not more debate.

Mistakes that spoil story points

Converting points to hours

The moment someone says "one point is four hours," you've got hours again, with extra steps. Let points stay relative.

Comparing teams by velocity

One team's 5 isn't another team's 5. Velocity is for forecasting your own team, not for league tables.

Point inflation

If a team is pressured to raise velocity, points quietly get bigger. The number goes up and nothing improves.

Estimating huge stories

If something is a 13 or more, split it. Large estimates are mostly noise.

A small tip on reference stories

Revisit your reference stories every few months. Teams get faster, tools change and an old 3 may now feel like a 2. When that happens, agree on a new anchor and keep going. Points are only useful while everyone shares the same picture of them.

Using estimates in sprint planning

Once you have sizes, planning becomes simpler. Look at your recent velocity, pick stories from the top of the backlog until you reach roughly that number, and check the result feels sensible. Our sprint planning best practices cover how to run the meeting, including what to do when the numbers and your gut disagree.

Tracking points in Sanplex

In Sanplex you can estimate stories and watch progress on Scrum and Kanban boards, so the sizes you agree in planning stay attached to the work through the sprint.

Frequently asked questions

What are story points?

Story points are a relative measure of how big a piece of work is, combining effort, complexity and uncertainty. They're used to plan sprints and forecast how much a team can finish.

What is the difference between story points and hours?

Hours estimate time directly and depend on who does the work. Story points estimate relative size and stay the same whoever picks up the story.

Why do agile teams use the Fibonacci sequence?

Because the gaps widen as numbers rise, which reflects the fact that larger work is harder to estimate accurately. It stops teams arguing over tiny differences.

Can I convert story points to hours?

You can, but it defeats the purpose. Converting points to hours reintroduces the problems points were meant to avoid, such as estimates being treated as promises.

What is planning poker?

It's a group estimation technique where each person privately chooses an estimate card, then everyone reveals at once and discusses differences until the team agrees.