Short definition
Story points are a unit of relative estimation in Jira - they measure how big or complex one issue is compared to another, not how many hours it will take. Teams pick a scale (most use the Fibonacci sequence: 1, 2, 3, 5, 8, 13) and assign points during refinement. Velocity, burndown, and sprint capacity reports all depend on the Story Points field.
Why relative estimation, not hours
Hour-based estimates are notoriously bad. Engineers underestimate by ~50% on average, and the error scales with task size. Story points sidestep this by asking a simpler question: is this story bigger than that one, or smaller? Teams are much better at relative comparison than at absolute time prediction.
After a few sprints, the team’s velocity (story points completed per sprint) emerges as a stable number. Velocity × sprint length becomes a reasonable forecast tool - not because points map to hours, but because the team is consistent enough that historic throughput predicts future throughput.
The Fibonacci scale
Most teams use 1, 2, 3, 5, 8, 13 (and sometimes 21 for “too big - split it”). The gaps between numbers grow on purpose: a 5 is meaningfully bigger than a 3, but the difference between 13 and 14 isn’t meaningful enough to capture. Forcing teams to pick from a small set keeps estimation fast and stops bikeshedding over 2-vs-3.
Where the Story Points field lives
On Cloud, the field is called Story point estimate by default. On Data Center, it’s Story Points. Both are numeric custom fields. They need to be on the Create Issue screen for whatever issue types the team estimates (usually Story, Task, and sometimes Bug), and on the Edit screen for refinement.
The field is also referenced by Jira’s Velocity Chart, Sprint Report, Burndown, Epic Burndown, and the sprint capacity indicator on the planning view. If the field is missing from a screen, the team can’t estimate during refinement - and reports will silently show wrong numbers.
Don’t estimate sub-tasks
Estimate at the story level, not on sub-tasks. Sub-tasks are how the story gets done, not separate work. Putting points on sub-tasks double-counts the work and breaks burndown. The single exception is teams that treat sub-tasks as standalone deliverables - rare and usually a sign the sub-tasks should have been stories.
Common questions
What are story points in Jira?
Story points are a unit of relative estimation - they measure how big or complex one issue is compared to another, not how many hours it will take. Teams pick a scale (most use the Fibonacci sequence: 1, 2, 3, 5, 8, 13) and assign points during refinement. Velocity, burndown, and sprint capacity reports all depend on the Story Points field.
How many hours is one story point?
There's no fixed conversion. The whole point of relative estimation is that one team's 3-point story is another team's 5. A team's velocity (points per sprint) gradually reveals how much real work fits in a point, but that number is local to that team. Don't try to standardize it across teams - the comparison breaks down.
What does a 13-point story mean?
In Fibonacci, 13 is usually the largest size a single sprint should accept. Anything bigger should be split. The gap from 8 to 13 reflects rising uncertainty - by the time work feels like a 13, the team can no longer reliably estimate it, which is itself a signal that the scope is unclear.
Should bugs have story points?
Opinions split. Pointing bugs gives accurate velocity but means a team can 'hit velocity' while shipping no new features. Not pointing bugs makes velocity feature-pure but understates real workload. Most teams point bugs and just report velocity broken down by issue type.