To add story points in Jira, turn on estimation for your board (Board settings > Estimation in company-managed projects, or Project settings > Features > Estimation in team-managed projects), then type the value into the Story point estimate field on each issue. Jira itself has no built-in planning poker voting, so you either install a Marketplace app or run the vote in a separate tool and type the agreed numbers back in, which takes about 15 to 20 seconds per issue.
This guide covers how Jira stores story points, how to set up estimation on a board, a copy-paste workflow for estimating Jira issues in any external planning poker tool, an honest comparison of your options, and how to keep a record of what the team decided and why.
How story points work in Jira
Jira treats story points as a number field on an issue. The field name and setup depend on your project type:
| Project type | Field name you'll usually see | Where estimation is configured |
|---|---|---|
| Team-managed (Cloud) | Story point estimate | Project settings > Features > Estimation |
| Company-managed (Cloud) | Story point estimate or Story Points | Board settings > Estimation > Estimation statistic |
| Data Center / Server | Story Points | Board configuration > Estimation |
A few things trip teams up:
- The board decides what "estimate" means. In a company-managed board, the Estimation statistic can be Story points, Original time estimate, or Issue count. Velocity charts and sprint reports read whichever one is selected. If the statistic is set to time, your story points exist on the issues but won't appear in the velocity report.
- The field has to be on the screen. If you can't see a story points field on a Story, a Jira admin usually needs to add it to the issue type's screen or extend the field's context to that project and issue type. This is the most common answer to "why can't I add story points in Jira."
- Jira takes a snapshot at sprint start. The velocity chart compares the points committed when the sprint started with the points completed. Changing an estimate mid-sprint shows up as scope change. (If you're deciding whether to re-estimate during a sprint, see re-estimating stories mid-sprint.)
- Sub-tasks don't roll up. Story points on sub-tasks are not added to the parent's points or counted in velocity. Estimate at the story level.
- The field ID varies. If you script against the API, the field is a custom field such as
customfield_10016, but the number differs between instances. Look it up rather than assuming.
How to add story points in Jira, step by step
- Confirm estimation is enabled (see the table above). For company-managed boards, set Estimation statistic to Story points.
- Open an issue. Find Story point estimate (or Story Points) in the details panel and type a number.
- In the backlog view you can also click the estimate badge on each issue row and edit it inline. This is the fastest way to update many issues after a planning session.
- If the field is missing, ask your Jira admin to add it to the screen for that issue type.
Jira accepts any number, including 4 or 6.5. Your team's scale (Fibonacci, modified Fibonacci, or T-shirt sizes mapped to numbers) is a convention you enforce, not a rule Jira enforces. If you haven't settled on a scale, the Fibonacci estimation guide and the Fibonacci vs T-shirt sizing comparison explain the tradeoffs.
Your three options for planning poker with Jira
There are three realistic ways to run a planning poker vote on Jira issues. None is best for everyone.
| Approach | How it works | Strengths | Tradeoffs |
|---|---|---|---|
| Native Jira only | PO reads the issue, team calls out or types numbers in chat, someone enters the result | No new tools, nothing to approve | No hidden voting, so the first number spoken anchors everyone else |
| Jira Marketplace app | Voting session runs inside Jira; agreed estimate is written to the field automatically | Points land in Jira with no retyping; issue details visible during voting | Needs a Jira admin to install; usually priced per Jira user; goes through your org's app security review |
| Standalone planning poker tool | Vote in a separate browser tool, then type the agreed numbers into Jira | Works for anyone, including people without Jira licenses; nothing to install in Jira | Manual write-back step; you need to keep track of which round was which issue |
When a Marketplace app is the right call
If your team estimates 30 or more issues a week, everyone already has a Jira license, and your admin can approve apps, an in-Jira app saves real time. The automatic write-back removes the transcription step and the risk of typing an 8 into the wrong issue. Check the listing for current pricing, hosting (Cloud vs Data Center), and data residency before you commit, since many apps price by the total number of users on your Jira site, not just the team using it.
When a standalone tool is the right call
Standalone tools win when:
- Your Jira admin is slow to approve apps, or your organization restricts Marketplace installs.
- Some estimators don't have Jira access (contractors, designers, a vendor team).
- You estimate 5 to 15 issues per session, so typing them back takes a few minutes at most.
- You want to try planning poker before asking for budget.
Be wary of any standalone tool that claims a "Jira integration" without telling you exactly what it does. Ask whether it reads issues from Jira, writes points back, or both, and what permissions it requests on your Jira site.
A copy-paste workflow: estimate Jira issues in any external tool
This is the workflow we recommend for teams using a standalone tool such as Alignlee's free planning poker. Alignlee has no Jira integration or API sync. You bring issue keys in by copying them and type the agreed points back. That sounds clunky, but for a typical refinement session it adds about five minutes.
Before the session (5 minutes, Product Owner or Scrum Master)
- In Jira, build a filter or use the backlog to list the issues you'll estimate, in the order you'll discuss them. A JQL starting point:
project = PROJ AND issuetype in (Story, Bug) AND "Story point estimate" is EMPTY AND status = "Ready for Refinement" ORDER BY Rank ASC
- Copy the keys and summaries into a scratch doc as a numbered list. The number becomes the round number in your poker tool.
Session: Sprint 24 refinement, 2026-10-07
1. PROJ-412 Export invoices as PDF
2. PROJ-418 Retry failed webhook deliveries
3. PROJ-420 Add audit log for role changes
4. PROJ-431 Fix timezone bug in scheduled reports
5. PROJ-433 Rate-limit public search API
- Share the Jira filter link in the meeting chat so everyone can open the full issue and acceptance criteria.
During the session
- Screen-share the current Jira issue. Read the summary and acceptance criteria aloud.
- Everyone votes privately. Reveal together.
- If votes are close, take the agreed number. If they spread wide (say 3 and 13), ask the highest and lowest voters to explain, then re-vote once.
- Note the agreed value next to the issue in your scratch doc as you go:
1. PROJ-412 ... = 5.
In Alignlee, rounds are exported as "Round 1", "Round 2", and so on rather than by issue key, which is why the numbered list matters: round N is item N on your list. Alignlee also shows a confidence-weighted result (for example 6.4) alongside the individual cards. Jira will happily accept 6.4, but most teams round to the nearest card on their scale before entering it, so velocity stays comparable sprint to sprint.
After the session (2 to 5 minutes)
- Open the Jira backlog filtered to the estimated issues.
- Click each estimate badge and type the agreed value from your scratch doc.
- Re-run the JQL filter. Anything still showing an empty estimate was missed or deferred.
- Comment on deferred issues with the reason ("needs spike on auth library", "waiting on API contract") so the next session doesn't start from zero.
How long the write-back actually takes
Here is a hypothetical refinement session to show where the time goes:
| Step | Issues | Time per issue | Total |
|---|---|---|---|
| Discuss and vote | 12 | about 4 min | 48 min |
| Re-vote on wide spreads | 3 | about 2 min | 6 min |
| Type agreed points into Jira backlog | 12 | about 20 sec | 4 min |
| Check the filter for misses | n/a | n/a | 1 min |
The write-back is around 5 minutes out of roughly an hour. If your sessions look like this, an integration is a nice-to-have, not a necessity. If you estimate 40 issues a week across several sessions, the math changes, and a Marketplace app or a small script starts to pay off.
Optional: write points back with a short script
Teams with a developer willing to own a script can update points through the Jira Cloud REST API. Put the agreed values in a two-column file (issue_key,points) and run something like this:
#!/bin/bash
# Usage: ./set-points.sh estimates.csv
# estimates.csv lines look like: PROJ-412,5
JIRA_SITE="your-site.atlassian.net"
JIRA_EMAIL="you@example.com" # Jira Cloud uses email + API token (basic auth)
JIRA_TOKEN="${JIRA_API_TOKEN}" # keep the token in an environment variable
POINTS_FIELD="customfield_10016" # look up your own field ID
while IFS=, read -r key points; do
curl -s -o /dev/null -w "$key -> %{http_code}\n" \
-X PUT "https://$JIRA_SITE/rest/api/3/issue/$key" \
-u "$JIRA_EMAIL:$JIRA_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"fields\": {\"$POINTS_FIELD\": $points}}"
done < "$1"
A 204 response means the update worked. A 400 usually means the field ID is wrong or the field isn't on that issue's edit screen. Practical cautions: use an API token rather than a password, never commit the token to Git, try it on a test project first, and remember the field ID differs between Jira sites. (On Data Center, personal access tokens use a Bearer header instead.)
Keeping a record of what the team decided
Jira stores the final number. It doesn't store how the team got there: who voted 13, what the risk was, why a story was deferred. That context is what you need three sprints later when someone asks why the export feature was a 5.
Options, from lightest to heaviest:
- Jira comment. One line on the issue: "Estimated 5 on 2026-10-07. Range was 3 to 8; the 8 was about PDF library licensing." Cheap and searchable.
- Session export. Alignlee exports meeting minutes as a Markdown file with each round's individual votes, confidence levels, and the result, plus a session summary. Attach it to your sprint's Confluence page or commit it to a team repo, and add your numbered issue list at the top so the rounds map back to Jira keys.
- Refinement log page. A running page per quarter with the date, issues estimated, and any notable disagreements. Useful when you later calibrate your story points against actual delivery.
Keeping these records matters most on regulated or audited projects, where being able to show how an estimate was reached is sometimes asked for.
Other Jira integrations Scrum teams ask about
Agile development tools that connect to Jira
The integrations that tend to pay for themselves are the ones that remove status updates people forget to make:
- Git provider (GitHub, GitLab, Bitbucket). Put the issue key in branch names and commit messages, and the development panel on the issue shows linked branches, commits, and pull requests. Smart commits like
PROJ-123 #comment fixed null check #time 2hcan add comments and log time from the commit message. - Automation rules. Jira's built-in automation can transition an issue when a pull request is opened or merged, flag stories in the backlog for 60+ days with no estimate, or add a "needs-refinement" label when acceptance criteria are empty.
- CI/CD. Build and deployment status on the issue helps in sprint review when stakeholders ask what's actually in staging.
Review these integrations every quarter. Tokens expire and webhooks get overwritten during upgrades, and integrations tend to fail without anyone noticing.
Requirements management tool Jira integration
Teams in regulated industries often keep formal requirements in a dedicated tool (Jama Connect, IBM DOORS Next, or a Jira-native requirements app) and implementation work in Jira. The usual pattern is that the requirements tool owns requirement text and traceability, Jira owns stories and status, and a connector syncs the link and status between them. Decide which system owns each field before you turn on sync, or you'll get edits fighting each other.
Rally Jira integration
Organizations running Rally (Broadcom) for portfolio planning alongside Jira for team execution generally connect them through Broadcom's own connector or a third-party sync tool. The same advice applies: pick one system as the source of truth for story points. If teams estimate in Jira, sync points one way into Rally, not both ways.
Common mistakes and fixes
| Mistake | What happens | Fix |
|---|---|---|
| Estimating sub-tasks | Velocity looks lower than the work done | Estimate stories; use sub-tasks for breakdown only |
| Board statistic set to time | Story points don't show in velocity | Board settings > Estimation > Story points |
| Typing decimals from a weighted average | Velocity drifts and is hard to compare | Round to the nearest card on your scale |
| Losing track of which round was which issue | Points land on the wrong issue | Numbered issue list before the session; re-check with JQL after |
| Re-estimating closed work after the fact | Historical velocity changes | Leave completed estimates alone; note the lesson instead |
For more on running the session itself, see how to facilitate planning poker and the backlog refinement guide.
FAQ
How do I add story points in Jira?
Enable estimation on the board (Board settings > Estimation for company-managed, Project settings > Features > Estimation for team-managed), then enter a number in the Story point estimate field on the issue or click the estimate badge in the backlog. If the field doesn't appear, a Jira admin needs to add it to the issue type's screen.
Does Jira have built-in planning poker?
Jira's core product gives you an estimate field but no hidden-vote planning poker session. Teams either install a planning poker app from the Atlassian Marketplace, which writes estimates to the field automatically, or vote in a standalone tool and type the agreed numbers back into Jira.
What are the best scrum tools for Jira?
Start with what removes manual work: your Git provider's Jira integration, Jira's built-in automation rules, and a planning poker method that hides votes until reveal. Whether that poker tool lives inside Jira or alongside it depends on whether your admin can approve apps and whether all estimators have Jira licenses.
Can I use a free planning poker tool with Jira?
Yes. Copy the issue keys into a numbered list, vote in the free tool, and type the agreed points into the Jira backlog afterwards. For a 10 to 15 issue session the write-back takes about five minutes, and nothing needs to be installed on your Jira site.
How do I sync Rally and Jira story points?
Use Broadcom's connector or a third-party sync tool, and make one system the owner of story points. Syncing points both ways causes conflicting edits, so most organizations estimate in the team's tool and push values one way to the portfolio tool.