Jira story points are a relative measure of effort, not time: they show how big a piece of work is compared with everything else in the sprint. You turn them on as the estimation statistic for your Scrum board or team-managed space, then type a number into the story point field on each work item.
Here's the part most teams get wrong. Atlassian's own guidance says to estimate each item once and leave that first number alone, even when you later find out it was off. Re-estimating makes some items more accurate than others, and that mix muddies your velocity, which is the number you plan the next few months with.
What a story point measures
Atlassian describes story points as a subjective unit that doesn't correlate to any amount of time. Its example: if a team has 30 story points in an iteration, a small task one person can finish quickly might be one point, while a task that eats the whole sprint would take all 30. The number only means something next to the other numbers on your board.
Story points are a Scrum tool. They're used both to estimate work items and to track progress on a board. By default you can only put them on story or epic work items, not on subtasks, although someone with Jira administrator permissions can change that through custom field contexts. Values must be numbers, but decimals are fine.
Story points or time estimates
| Story points | Time estimate | |
|---|---|---|
| What it measures | Effort compared with other work in the sprint | How long the work should take |
| Field name | Story point estimate (team-managed) or Story Points (company-managed) | Original estimate |
| What you type | A number, decimals allowed | Weeks, days, hours or minutes, for example 1w 2d 3h 4m |
| Extra setup | None once estimation is on | Needs the Time tracking field added alongside it |
Atlassian explains why it moved away from hours. In the traditional approach a team estimates in man-hours, adds them up and divides by headcount to get a date. Those numbers ignore the team's habit of over or under-estimating, the interruptions that land in the middle of the work, and how people's performance changes over time. Because story points aren't tied to time, they break that mental link, and the team stops chasing an accuracy it can't reach.
Turning on estimation in a team-managed space
- Open your team-managed software space.
- Next to the space name in the sidebar, select More actions (•••), then Space settings.
- Enable the Estimation feature.
- Choose whether to estimate with Story points or Time.
- Check a work item: the Story point estimate or Original estimate field is added automatically.
If you never pick an estimation statistic, Jira measures work by work item count. Turning estimation off later doesn't wipe anything: the data stays hidden and comes back if you switch the feature on again or add the field back to the work type. The story point field is available to all standard-level work types, and you can add it to epics too.
Adding points to a work item
In a company-managed Scrum space, estimating happens before the sprint starts. Go to the Backlog, select a work item and enter a number in the Story points or Original estimate field, depending on the estimation statistic your board uses. In a team-managed space the field also shows wherever you open a work item, including the board and the roadmap.
The fastest route is the command palette. Open a work item in the sidebar or full screen, press command + K on a Mac or Ctrl + K on Windows, and search for the action that matches your space type.
| Action | Team-managed space | Company-managed space |
|---|---|---|
| Add | Add story point estimate | Add Story Points |
| Change | Edit story point estimate | Edit Story Points |
| Remove | Remove story point estimate | Remove Story Points |
Type the number and press enter. The palette closes and the estimate updates.
Why Atlassian says leave the first estimate alone
Say work item X has an original estimate of five days, and before the next sprint the team realises it's closer to 15. It feels risky to keep the five. Atlassian's point is that estimates will always be wrong, some a little and some wildly, and you'll usually find out after the sprint starts. If the team estimates the same way across the whole backlog, it evens out. A team that always underestimates might find that in a 10-day sprint with four people it can only commit to 20 days of its estimation unit, and with a stable velocity that's fine.
The second example is the one I'd show any team lead. A work item is estimated at 10 days. The team works five days on it, then drops it to fix an urgent bug, and it goes back to the backlog. It's finished in the next sprint. Use the remaining estimate and velocity across those two sprints comes out at 2.5 days. Use the original estimate and it's five days. The original number quietly accounts for the unplanned work that will keep happening.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Atlassian also advises against adding up subtask estimates for velocity. Subtask estimates are more accurate than story estimates, so mixing them makes velocity useless for looking further down the backlog, only the top items tend to be broken into tasks, and subtask totals ignore interruptions. That said, Jira supports remaining estimates, hours and subtask hours if your team prefers them.
My verdict on Jira story points
I'd use story points if you run Scrum and want to know how much of the backlog you'll get through in the next few sprints. Estimate once, don't keep revising, and let velocity do the forecasting. If what you need is a record of hours spent, use the Original estimate and Time tracking fields instead. Estimating happens in the backlog, so it's worth keeping your Jira backlog in order, and if you're unsure which items can carry points, here's how Jira issue types fit together.
Estimates only help when the team trusts the process behind them. Helping teams work smarter is what I do. I run AI training and workshops for teams, and help businesses with AI and workflow enablement, AI automation and GEO, which is about getting your business seen and cited in AI answers. Most of that work is with SaaS marketing teams and small businesses. Here's how we can work together.
Frequently asked questions
Are Jira story points the same as hours?
No. Atlassian calls story points a subjective unit that doesn't correlate to any amount of time. They express effort compared with other work in the sprint.
Can you put story points on subtasks in Jira?
Not by default. Story points can only be assigned to story or epic work items unless a Jira administrator changes the custom field context.
Can Jira story points have decimals?
Yes. Story point estimates must be numbers, but they can include decimal points.
What happens to story points if I turn estimation off?
Nothing is lost. The data stays hidden and comes back if you enable estimation again or add the field back to the work type.
What does Jira measure if no estimation statistic is set?
If you don't select an estimation statistic, work is measured by work item count.
