Short definition
A story estimate in Jira is the size assigned to a backlog item before it's worked, usually in story points but sometimes in hours, t-shirt sizes, or a custom unit. The estimate goes in the Story Points field (or a configured custom estimation field) and feeds velocity charts, burndown reports, and sprint capacity planning. Estimates are relative measures of effort, complexity, and uncertainty - not time.
What the estimate captures
A story estimate is a relative measure of how big a story is compared to other stories the team has worked on. It bundles together three things:
- Effort - how much work is required.
- Complexity - how many moving parts, integrations, unknowns.
- Uncertainty - how confident the team is in its understanding of the story.
The combination matters: a story with low effort but high uncertainty (because the requirements are fuzzy) is sized larger than one with the same effort but clear requirements. That’s why estimates aren’t time - “this is a 5” means “this is roughly the same size as the other 5-point stories we’ve done,” not “this will take 5 hours.”
Estimation scales
Two common scales:
- Modified Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100) - the most popular. Gaps grow as size increases, reflecting that large estimates are less precise.
- T-shirt sizing (XS, S, M, L, XL, XXL) - simpler, often used during early refinement before switching to numeric for sprint planning.
A few teams use ideal hours or days as their unit, but this conflates estimate with calendar time and typically loses the relative-sizing benefit.
Where the estimate lives
Jira’s default estimation field is Story Points. Some teams replace it with a custom number field for organisational reasons (different scale, separate fields for effort vs. complexity, etc.). The field actually used by velocity and burndown is configured per board in the board settings, not per project.
This is a common gotcha: a team creates a custom estimation field, populates it, then wonders why the Velocity Chart still reads zero - because the board is still configured to read from Story Points. Custom Fields for Jira makes it easy to find which fields are wired into which boards.
Estimate hygiene
Two periodic checks:
- Issues in the sprint with no estimate. JQL:
sprint in openSprints() AND "Story Points" is EMPTY AND statusCategory != Done. These break burndown. - Issues closed without an estimate. JQL:
statusCategory = Done AND "Story Points" is EMPTY AND resolved >= -30d. These are velocity-invisible work that the team did but won’t show in throughput data.
See also (Redmoon products)
Common questions
What is a story estimate in Jira?
A story estimate is the size assigned to a backlog item before it's worked, usually in story points but sometimes in hours, t-shirt sizes, or a custom unit. The estimate goes in the Story Points field (or a configured custom estimation field) and feeds velocity charts, burndown reports, and sprint capacity planning. Estimates are relative measures of effort, complexity, and uncertainty - not time.
How do teams estimate stories?
Most teams use planning poker: each team member picks a card from a Fibonacci-style sequence (1, 2, 3, 5, 8, 13, 20, 40) representing relative size, the cards are revealed simultaneously, and outliers explain their reasoning. Discussion converges on a shared estimate. The point is the conversation - the number is the artifact.
Should bugs be estimated?
Mostly yes. Bugs that take real effort deserve estimates so they're visible in velocity and capacity planning. Bugs that are trivially small (under an hour) are often left unpointed by convention. Teams that never estimate bugs end up with sprints where actual capacity gets eaten by 'small' bug work that wasn't accounted for.
What happens if a story has no estimate?
It contributes nothing to velocity even when completed, breaks burndown lines (the chart shows a vertical drop when the story closes), and confuses capacity planning. Some teams enforce 'no estimate, no sprint' via a workflow condition. If estimating in the moment isn't possible, give it a placeholder size that you'll refine later.