Your team has to say how long the next feature will take, and every number in hours feels like a promise someone will hold you to. Story point estimation takes a different route. Instead of guessing hours, the team gives each backlog item a number that shows how much effort it needs compared with other items: a 4 is about twice the work of a 2. Points cover the amount of work, its complexity and its risk in one figure, and the team converts them into dates later, using how many points it actually finishes per sprint.
So the short answer to “story points vs hours” is this: points are for sizing and forecasting a backlog when the work is uncertain, and hours are for scheduling, billing and checking what the work really cost. Most teams end up needing both. This guide explains how the point scale works, how to run an estimation session, how many hours a point is (and why there is no fixed answer), and where each approach falls short.
What is story point estimation?
Story point estimation is a relative sizing method used mostly by Agile and Scrum teams. Each item in the product backlog, whether a new feature, a bug fix or a technical change, gets a number of points. Mike Cohn of Mountain Goat Software defines story points as “a unit of measure for expressing an estimate of the overall effort” needed to finish an item.
Three things go into that single number:
- the amount of work, meaning how much there is to build, test and review;
- complexity, meaning how hard the work is to get right;
- risk and uncertainty, meaning unclear requirements, unfamiliar code or dependencies on other people.
The team does not score these separately and add them up. It weighs them together and agrees on one figure. The raw value matters less than the ratio: what counts is that an item rated 4 needs roughly twice the effort of an item rated 2.
Points started as a workaround. Ron Jeffries, one of the creators of Extreme Programming, writes that early teams estimated in “ideal days” and then multiplied them by a load factor to get calendar time. Stakeholders were confused by “days” that did not match the calendar, so the team started calling them points. The Scrum Guide itself does not prescribe any unit: it says only that “the Developers who will be doing the work are responsible for the sizing”.
Story points vs hours: which estimate fits your work?
Estimating in hours asks “how long will this take?” Estimating in points asks “how big is this compared with that?” The second question is easier to answer when the work is new, because people judge relative size more consistently than absolute duration. Hours win when you need a schedule, a quote or a payroll figure.
| Question | Story points | Hours |
|---|---|---|
| What it measures | Relative effort: work, complexity and risk in one number | Expected duration of the work |
| Who it belongs to | The whole team; a point means something only inside that team | Often one person; an hour means the same everywhere |
| Effect of a slower or faster person | The estimate stays the same; velocity changes | The estimate has to be redone |
| How you get a date | Divide remaining points by average velocity | Add up hours and map them onto people’s schedules |
| Good fit | Product backlogs, release forecasting, uncertain or new work | Client quotes, fixed budgets, billing, payroll, repeatable tasks |
| Main weakness | Hard to explain to clients; easy to misuse as a performance score | Invites false precision and pressure to “hit the number” |
If your team works on a product backlog and plans in sprints, points are usually the better planning tool. If you sell time to clients or run a fixed price project, you still need hours, and the practical answer is to estimate in points for planning and estimate and track in hours for anything financial.
How many hours is 1 story point?
There is no standard conversion. One story point is not one hour, one day or any other fixed unit, because a point only means something relative to the reference items a particular team chose. Cohn warns against rules like “One story point = eight hours”, and the Mountain Goat planning poker guide adds that if each card secretly means a number of hours or days, the team loses the benefit of relative estimation.
What you can do is work out how much time your team’s points have taken in the past. The usual way is velocity: the number of points the team completes per sprint. The example below uses made up figures to show the arithmetic.
The last line is a team average over several sprints, not a rate you can apply to a single story. A 3 point item might take 20 hours one week and 50 the next. Use the ratio for budgeting a whole release and keep velocity as the forecasting tool. If your velocity swings a lot from sprint to sprint, give stakeholders a range (for example, 25 to 35 points per sprint) rather than one date.
Story point scales: Fibonacci, modified Fibonacci and T-shirt sizes
The scale is the set of values the team is allowed to pick from. Most teams use a sequence where the gaps grow as the numbers grow, because the bigger an item is, the less precisely anyone can size it. Arguing over 14 versus 15 is wasted time; choosing between 13 and 20 forces a real decision.
| Scale | Typical values | When teams use it |
|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21, 34 | The default for many Scrum teams |
| Modified Fibonacci (planning poker deck) | 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 | Teams that want a “tiny” value and round numbers for large items |
| T-shirt sizes | XS, S, M, L, XL | Early roadmap sizing, before items are well understood |
| Powers of two | 1, 2, 4, 8, 16 | Teams that prefer doubling as the only step |
The modified deck with ½ comes from commercial planning poker cards described on Wikipedia’s planning poker entry; the deck on Mountain Goat Software’s page starts 0, 1, 2, 3. Whichever you choose, keep it fixed so that last quarter’s 5 means the same as this quarter’s 5. The underlying Fibonacci sequence has no special link to software; teams use it simply because its gaps widen at a useful rate.
How to do story point estimation step by step
The process below works for a new team estimating its first backlog. Once the team has a few sprints of history, steps 1 and 2 only need a refresh now and then.
-
Choose a scale and write it down.
Pick one of the scales above and agree on a cap. Many teams decide that anything above 13 is too big to commit to in a sprint and must be split first.
-
Pick reference stories.
Choose a small item the whole team understands well and call it a 2 or a 3. Add one or two other finished items as anchors at 5 and 8. Every new estimate is a comparison with these, so choose items people remember clearly.
-
Prepare the items to be estimated.
Write each backlog item as a user story or another clear description with acceptance criteria. An item nobody can explain cannot be sized, so the product owner should be ready to answer questions.
-
Discuss work, complexity and risk.
Talk through what has to be built and tested, what makes it hard and what could go wrong, such as an unclear requirement, legacy code or a dependency on another team. This conversation is where most of the value of estimation comes from.
-
Estimate together and converge.
Everyone picks a value privately, all values are revealed at once, and the people with the highest and lowest numbers explain their reasoning. Repeat until the numbers are close enough to agree on. Planning poker, described below, is the most common format.
-
Split anything above your cap.
A 21 or 40 is a signal that the item hides several pieces of work. Break it into smaller stories and estimate those instead.
-
Forecast with velocity, not with a conversion rate.
After two or three sprints, divide the remaining points by your average velocity to forecast how many sprints are left. Present the forecast as a range.
-
Review estimates after the sprint.
Look at items that turned out much bigger or smaller than estimated and ask what the team missed. Do not “correct” old estimates; use the lesson on the next ones.
Story point estimation techniques
The steps stay the same; what changes is how the team reaches agreement. Choose the technique by backlog size and how much discussion each item needs.
Planning poker
James Grenning described and named planning poker in 2002, and Mike Cohn popularized it in his 2005 book Agile Estimating and Planning (source). The product owner presents one item, the team asks questions, each estimator chooses a card in private, and everyone reveals at the same time. If the values differ, the high and low estimators explain their thinking and the team votes again. Revealing at once stops the first number spoken from anchoring everyone else. According to Mountain Goat Software, the people doing the work should be the ones estimating.
T-shirt sizing
Items are sorted into XS, S, M, L and XL. It is quick and easy for non technical stakeholders to follow, which makes it useful for roadmap sizing. Teams that need velocity later map each size to a point value.
Affinity estimation
The team silently places item cards on a wall from smallest to largest, then discusses only the cards people moved back and forth, and finally groups the line into point values. It handles dozens of items in one session, so teams use it for a first pass on a large backlog.
Bucket system
The point values are laid out as “buckets”, and team members place items into them, starting with a few items discussed as a group and then dividing the rest. Like affinity estimation, it trades some discussion for speed.
For methods that produce hours rather than points, such as three point estimation, analogous estimation or the Delphi method, see our overview of project estimation techniques.
Story points in Jira
In Jira, estimation is set per Scrum board. According to Atlassian’s documentation for Jira Software Data Center, a board administrator opens the board settings, goes to the Estimation tab and picks the estimation statistic, which can be Story Points, Original Time Estimate, Issue Count or another numeric field. Once Story Points is selected, team members enter the agreed value in the Story Points field of each issue. By default that field is available for Story and Epic issue types; an administrator can add it to other issue types such as bugs. Jira Cloud menus are labeled slightly differently, so check Atlassian’s current help pages for your edition.
Advantages and drawbacks of story point estimation
Points earn their place when work is uncertain. They are a poor fit when someone outside the team needs a firm number in hours.
What points do well
- Relative judgments are easier than absolute ones, so estimates are quicker to agree on, especially for unfamiliar work.
- The estimate does not change when the team speeds up or slows down. Only velocity moves, so you recalculate the forecast instead of estimating every item again.
- Estimating as a group surfaces risks that one person would miss, and the discussion often matters more than the number.
- Points describe the work rather than a person, which removes some of the pressure people feel when an hour estimate turns into a personal deadline.
Where points fall short
- Clients, finance and leadership think in hours, days and money, so someone always has to translate.
- Points are not comparable between teams. One team’s 5 can be another team’s 13.
- Velocity is easy to misuse as a productivity score. Once it becomes a target, estimates tend to inflate.
- The method needs a stable team and a few sprints of history before forecasts become useful.
Even the person who may have coined the term is skeptical. In a 2019 post, Ron Jeffries calls himself sorry if he invented story points, criticizes comparing teams by velocity and suggests teams drop points if they provide little value, preferring to slice stories small enough to deliver value often. In our view that is a fair challenge: if your items are all small and similar, simply counting them may forecast as well as pointing them.
Common story point estimation mistakes
- Fixing a conversion rate. “1 point equals 1 day” turns points back into hours with extra steps.
- Letting the manager estimate. The people who will do the work should size it; the product owner clarifies but does not vote.
- Changing estimates on finished work to match actuals, which makes velocity meaningless.
- Comparing velocity across teams or using it in performance reviews.
- Estimating huge items instead of splitting anything above your cap before it enters a sprint.
- Ignoring optimism. Teams underestimate for the same reasons individuals do, and our article on the planning fallacy explains why and what helps.
Using story points and tracked hours together
Many teams that plan in points still have to report hours: agencies and consultancies bill clients by time, internal teams report cost to finance, and everyone wants to know whether the last release took as long as expected. Points do not answer those questions, and tracked time does.
In actiTIME, you can set an estimate in hours on each task, track time against it in a weekly timesheet or with the mobile app, and compare the two in the Estimated vs. Actual Time Report. Tasks can also carry custom fields, so a team can add a numeric field to record the agreed points next to the hour estimate. Over a few sprints, that gives you real data on how much time your points take, which is the honest version of the conversion rate people keep asking for. The step by step guide to time estimation in actiTIME shows the setup.
Now we can better predict future project requirements
Our company needed a simple way of tracking time used on multiple projects – and actiTIME fit the need. Its interface is simple and easy to maintain. We use the application for time management, task estimation and also to communicate deadline information to our team members. Now having actiTIME we can better predict future project requirements!
FAQ
Does 1 story point mean 1 day?
No. A story point has no fixed time value. It shows effort relative to the team’s reference items, so its meaning in hours differs from team to team and changes as the team’s velocity changes. To link points to time, divide the hours your team tracked over several sprints by the points it finished in them, and treat the result as an average for the whole release, not for one story.
Can we have 0.5 story points?
Yes, if your scale includes it. The modified Fibonacci deck used in many planning poker sets has a ½ card for very small items. Many teams leave it out and use 1 as the smallest value, because tiny items add little to forecasts and can be grouped instead.
How are story points assigned in Agile?
The people who will do the work assign them together. They compare each backlog item with reference items, discuss the amount of work, its complexity and its risks, and agree on one value from the team’s scale, often through planning poker. The product owner explains the item but does not estimate.
How do I add story points in Jira?
A board administrator selects Story Points as the estimation statistic in the board settings under Estimation. Team members then enter the value in the Story Points field of each issue. By default the field appears on Story and Epic issues; an administrator can add it to other issue types.
What is velocity in story point estimation?
Velocity is the number of story points a team finishes in one sprint, usually averaged over the last three or more sprints. Dividing the remaining backlog by velocity gives a forecast of how many sprints are left. Velocity is a planning tool for one team and should not be compared across teams.
Why do teams use the Fibonacci sequence for story points?
Because the gaps between values grow as items get bigger, which matches how uncertainty grows with size. It stops teams from debating small differences on large items and pushes them to split work that lands at the top of the scale.
Are story points better than time estimates?
For sizing and forecasting an uncertain product backlog, points are often easier to agree on and more stable. For quotes, fixed budgets, billing and payroll, time estimates are necessary. Many teams plan in points and estimate and track hours for anything financial.
Who should take part in story point estimation?
Everyone who will build, test or review the item: developers, testers, designers and analysts. The product owner joins to answer questions, and a facilitator, often the Scrum Master, keeps the session moving.
Conclusion
Story point estimation works best when the team treats points as a relative size, keeps its reference stories stable and gets dates from velocity rather than a fixed conversion. When clients or finance need hours, track them alongside the points so you can see what your estimates really cost.
actiTIME lets you set task estimates, track time against them and compare estimated and actual hours in one report. Start a free 30-day trial, or book a demo if you want a walkthrough.
