Story points estimate the relative size of a piece of work: its complexity, the amount of work and the uncertainty. Hours estimate how long it will take. Use story points to plan sprints and forecast with velocity. Use hours to bill clients, track budgets and check how long work really took. Teams that bill or work to a budget usually need both.
Key takeaways
- Points are for planning. Hours are for money and for learning.
- Do not convert points to hours when you plan. It turns points back into deadlines.
- You can record actual hours without estimating in hours.
- Looking at hours per point after the fact improves both estimates.
What is the difference?
| Story points | Hours | |
|---|---|---|
| What they measure | Relative effort, complexity and risk | Elapsed working time |
| Unit | Abstract, and specific to one team | The same for everyone |
| Set by | The team, together | Usually one person |
| Good for | Sprint planning and forecasting | Billing, budgets, payroll and capacity |
| Compared across teams? | No | Yes |
| Typical failure | Treated as hours in disguise | Treated as a promise |
Why do agile teams estimate in points?
Atlassian's agile guidance describes story points as units of measure for the overall effort needed to fully implement a backlog item. It gives several reasons teams prefer them to dates and hours.
Hidden work
Dates do not account for the email, meetings and interviews that fill a real week.
Less emotion
A date feels like a promise. A relative size does not.
Team-specific
Each team sizes work its own way, so one team's velocity cannot be held up against another's.
Rewards problem solving
Points reflect difficulty, not time at the keyboard.
The same guidance suggests breaking down anything estimated above roughly 16 hours, or 20 points. Large items hide too much uncertainty to estimate well in either unit.
Why do you still need hours?
Because the world outside the team runs on time and money.
Questions that only hours can answer
- What do we invoice this client for March?
- How much of the project budget is left?
- How much capacity do we have next quarter?
- What did this feature cost to build?
- How much of the team's time goes to maintenance?
None of these needs an estimate in hours. They need a record of actual hours.
Can you convert story points to hours?
Not in planning. The moment "one point is six hours" is written down, points become hours with extra steps, and every benefit in the cards above is gone.
After the fact is different. You can look back and see what a point has tended to cost.
Hours per point = actual hours logged ÷ story points completed
Example: 312 hours logged in a sprint that completed 40 points = 7.8 hours per point
Use that number to forecast the cost of a backlog. Do not hand it to the team as a target, and expect it to differ by kind of work.
What does hours per point tell you?
| Pattern | What it suggests |
|---|---|
| Stable from sprint to sprint | Estimates are consistent. Forecasts can be trusted |
| Rising over several sprints | Hidden work is growing: support, meetings or technical debt |
| Very different by type of work | Bugs and features need separate forecasts |
| Wildly variable | Stories are too large, or time is not being recorded |
When should you use which?
Use story points for
- Sizing backlog items
- Sprint planning with velocity
- Forecasting when a release will be ready
- Talking about risk and complexity
Use hours for
- Invoices and client reports
- Project budgets
- Capacity and staffing plans
- Checking estimates against reality
How do you run both without doubling the work?
Estimate in points
In planning, as a team. No hours discussed.
Record hours automatically
Time is captured against each issue as the work happens, with no timesheet to fill in.
Leave the two alone during the sprint
Nobody is asked why a three-point story took eleven hours.
Compare at the retrospective
Look at hours per point by type of work, and at stories far from the norm.
Forecast cost from history
Points left in the backlog × hours per point × rate.
The second step decides whether this works. If recording hours means a second round of manual entry, developers will resent it and the numbers will be poor. See time tracking for developers.
What about estimating in hours in Jira?
Jira supports both. An issue can carry story points and an original estimate in time, and work logged against it adds up as time spent. How those fields behave is covered in original estimate, time spent and remaining estimate.
How does BirdsEye fit in?
BirdsEye records the hours side without asking developers to log anything.
- Issue picker. Developers choose a Jira issue as their task in the desktop agent.
- Automatic time. Working time is recorded against that issue inside working hours.
- Worklogs that stay correct. BirdsEye creates, updates and removes Jira worklogs so that time spent in Jira matches tracked time.
- Budgets in hours. Projects can carry an hour budget, with a report of hours by person and task.
Your points stay in Jira, set by the team. BirdsEye does not read or change story points. Jira is available on the Team and Business plans. See Jira time tracking.
Frequently asked questions
What is a story point?
A unit a team uses to express the relative effort of a backlog item, taking in complexity, the amount of work and risk or uncertainty. It is not a measure of time.
How many hours is one story point?
There is no fixed answer, and assigning one defeats the purpose. You can measure what a point has cost your team on average by dividing hours logged by points completed.
Should we estimate in hours or story points?
Points for planning sprints, hours for anything involving money or capacity. Many teams estimate in points and record actual hours.
Can you use story points and time tracking together?
Yes. Estimate in points, record hours against issues as work happens and compare the two at the retrospective.