How to estimate story points in Jira

To estimate story points in Jira, set your board to estimate in story points, then enter the agreed number in the story point field on each work item, usually in the backlog during refinement. Where you do that depends on the type of space. Company-managed spaces use a field called Story Points, configured in the board’s settings under Estimation. Team-managed spaces use a field called Story point estimate, which appears once you switch on Estimation in the space settings, under Features.

Jira only stores the number; choosing it well is the team’s job. If you’re new to story points, start with what they measure. This guide covers Jira Cloud: the settings, where your estimates show up and the habits that keep them meaningful. A note on words: Atlassian now calls projects “spaces”, issues “work items” and issue types “work types”, although older guides, and a few corners of Jira, still use the old names.

First, check whether your space is company-managed or team-managed

Almost everything about story points in Jira depends on the space type. To check yours, select More actions (•••) next to the space name, in the header or the sidebar. The differences that matter for estimation:

The two story point fields are separate fields, not two names for the same one. That matters when you build filters, move work between spaces or connect other tools, which all need to use the right field.

Set up story points in a company-managed space

1. Open the board settings. On your Scrum board, select More actions (•••) next to the board name, then Board settings.
2. Choose story points. Select Estimation, then set the Estimation method to Story points.
3. Decide on time tracking. Leave Time tracking at None to track progress in story points. Choose Remaining estimate and time spent only if the team also logs hours and wants progress measured that way.
4. Check the field on every work type you estimate. If the Story Points field doesn’t appear on bugs or tasks, a Jira admin needs to add those work types to the field’s context and make sure the field is on the right screens.

Only a space administrator for the board’s location, or a board administrator, can change these settings. Atlassian’s own training notes that the estimation feature is only available on Scrum boards.

Set up story points in a team-managed space

1. Open the space settings. Select More actions (•••) next to the space name in the sidebar, then Space settings.
2. Turn on Estimation. Select Features and switch on Estimation.
3. Choose Story points. Pick Story points rather than Time as the estimation statistic.
4. Add the field to epics if you size them. Jira adds Story point estimate to all standard-level work types automatically; epics need it added through the work type settings.

Story point estimates in team-managed spaces must be numbers but can include decimals, so 0.5 works. If you later switch Estimation off, or remove the field from a work type, Jira hides the existing estimates rather than deleting them, and they reappear when you switch it back on.

Where to enter estimates, and how to spot gaps

The backlog is the natural place to estimate. Select a work item and type the agreed number into the story point field, and it shows against the item in the backlog. For each sprint, the backlog also adds up the story points and splits the total by status (to do, in progress and done), worked out from the board’s columns. Before you start a sprint, compare that total with the team’s recent velocity.

To find items that still need an estimate, save a filter. These examples use a space with the key PAY. JQL still accepts “project”, which Atlassian has kept for backwards compatibility alongside the newer “space”.

If several items end up with the same estimate, for example after a bucket-system session, select them in the backlog and choose Edit, then Fields, to set the value on all of them at once. This works when the field applies to every item you’ve selected.

On planningpoker.org With a free Laya account and a Jira connection in your workspace, you can pick issues from a Jira board and estimate them with planning poker. Save & Next can write the agreed estimate back to Jira, by default to the board’s own estimation field.

Where your estimates show up in Jira

Estimates feed Jira’s Scrum reports, and each report has its own rules about changes. Knowing them saves a lot of confusion in sprint reviews.

• Velocity chart. For each sprint, a grey commitment bar shows the total estimate of the work items in the sprint when it started, and a green completed bar shows the estimates of the work finished by the end. Work added after the start, and estimates changed after the start, don’t count towards the commitment, while the completed bar does include scope changes.
• Sprint report. Lists the work in a sprint. Items added after the sprint started are marked with an asterisk, and an estimate changed during the sprint shows both values with an arrow, such as 3 → 5.
• Burndown chart. Tracks the work remaining in a sprint using the board’s estimation statistic. Story points on sub-tasks aren’t included.
• Team-managed reports. Team-managed spaces have their own burnup and velocity reports for sprints, which use the estimates on your work items.

The practical lesson: estimate everything before you press Start sprint. An item estimated afterwards adds nothing to the commitment, yet counts in full towards the completed bar once it’s done, so the two stop being comparable.

How to keep estimates consistent

Jira accepts any number in a story point field: 4, 7, 2.5 or 400. Consistency has to come from the team. These habits do most of the work:

• Agree one deck. Pick your values, for example 0.5, 1, 2, 3, 5, 8 and 13, and treat anything bigger as a sign to split the story. A stray 4 or 6 makes velocity harder to read and suggests nobody voted.
• Estimate as a team. The number in the field should be the team’s estimate, agreed in planning poker or a similar session, not the assignee’s guess typed in later.
• Keep reference stories. Link two or three finished items of known size from the team’s working agreement, so new items are compared against the same yardsticks. Our guide to reference stories explains how to choose them.
• Estimate stories, not sub-tasks. Atlassian’s guidance warns against using sub-task estimates for velocity: they are more detailed than story-level estimates, so mixing the two gives velocity a blend of high- and low-accuracy numbers. Size the story, and let sub-tasks break down the work.
• Decide about bugs and spikes once. Whether you point planned bugs or timebox spikes matters less than doing the same thing every sprint, so velocity counts the same kinds of work.
• Use one field per board. Reports read the field the board is configured to use. If one team types into Story Points and another into a home-made “Points” field, half the work disappears from the charts.

When to re-estimate, and when to leave it alone

Atlassian’s documentation is firm: teams should estimate each item once and not change the estimate after learning more, because updating estimates would pollute velocity. Velocity works because every sprint’s numbers were produced the same way, before the work started. Revise some estimates with hindsight and some sprints end up with more accurate numbers than others, so the average stops being a fair guide.

In practice that gives three rules:

• Before the sprint, re-estimate when the item changes. If the product owner adds a requirement, or the team learns something that changes the work before anyone starts, vote again. You’re estimating a different item.
• During the sprint, leave it. If a story turns out bigger than expected, keep the estimate and talk about the surprise in the retrospective. If genuinely new scope appears, create a new item for it instead of inflating the old one.
• After the sprint, never. Changing a finished item’s estimate to match the effort it took turns story points into a timesheet.

For example, “PAY-231 Retry failed card payments with exponential backoff” was estimated at 5. Two days before sprint planning, the product owner adds a requirement to retry on the customer’s backup card if they have one. That’s a different item, so the team votes again and settles on 8. Had the same discovery come mid-sprint, the better move would have been a separate item for the backup-card retry.

Reporting and forecasting with story points

Once estimates are consistent, the velocity chart becomes a forecasting tool. Read the completed bars as a range rather than a single number. If a team’s last four sprints show 24, 31, 27 and 22 points, it can reasonably plan for 22 to 31 points, adjusted for holidays and other commitments, and use that range in sprint planning.

Three cautions keep the reports honest:

• Don’t compare teams. Each team’s scale is its own; a team with a velocity of 40 isn’t doing twice the work of a team with 20.
• Don’t convert points to hours. Jira keeps story points and time tracking in separate fields for good reason. If someone needs a date, forecast a range of sprints from velocity.
• Watch the trend, not the sprint. One low sprint is noise. A steady fall over five or six sprints is a conversation for the retrospective.