Planning poker with Jira
What the integration does
Connecting Jira to a team turns planning poker from retyping into a two-click setup:
- Import issues into a game — by sprint, or by a JQL query when a sprint is not the right unit.
- Keep the issue's details visible while voting — summary, description, assignee and reporter travel with the task, so nobody has to switch tabs mid-estimate.
- Read the existing estimate — an issue that already carries story points arrives with that value, so the team can see what it was estimated at before.
- Write the agreed estimate back — the story point field on the issue is updated from the revealed votes.
The integration belongs to the team, not to the person who set it up. Participants join the game from a link and never need a Jira account of their own.
Read-only or write access
Jira is connected through OAuth, and there are two permission sets:
| Read-only | With write access | |
|---|---|---|
| Search issues, import them into a game | Yes | Yes |
| List sprints and import a whole one | Yes | Yes |
| Read an issue's existing story points | Yes | Yes |
| Write the agreed estimate back to the issue | No | Yes |
Start read-only if that is what your Jira administrator will approve — everything except the write-back works, and the estimate simply stays in QRetro. Permissions can be upgraded later without reconnecting from scratch.
Running a session against a sprint
- Connect Jira once. Team settings → Integrations → Jira, then authorise. This is a per-team step, done by someone with the right to grant it.
- Open a game and pick a scale. Fibonacci is the default; see the Fibonacci scale for why the gaps widen.
- Import the sprint. Pull in the sprint's issues, or use a JQL query for a narrower set — anything unrefined is better left out than estimated badly.
- Share the game link. Participants join in the browser without an account.
- Estimate one issue at a time. Everyone votes, all cards reveal at once, the outliers explain. The full session shape is on the planning poker page.
- Sync the estimate back. The agreed value is written to the issue's story point field.
What gets written, and what does not
The estimate is computed from the revealed votes — there is no way to type a number in directly, which keeps the value traceable to an actual round of voting.
Before anything is sent to Jira the value is validated, so the non-numeric cards never reach the issue:
?— "cannot estimate yet". Nothing is written; the issue goes back to refinement.☕— a break request, not an estimate.- T-shirt sizes — not numeric, so a game on that scale cannot sync to a story point field. Use Fibonacci or powers of two if the estimate has to land in Jira.
- 0 — accepted by Jira and written as zero.
QRetro locates the story point field automatically. It is a custom field whose identifier differs between Jira sites, which is why it cannot simply be hard-coded.
If you use Linear instead
Linear works the same way — import issues or a cycle, estimate, write the value back to the issue's estimate field. Two differences come from Linear itself rather than from QRetro: estimates are capped at 64, and Linear does not accept zero, so a zero is sent as "clear the estimate" instead. Both trackers can be connected to the same team.
From your editor
The same operations are available over the Model Context Protocol, so Claude, Claude Code, Cursor and VS Code can open a game, import a sprint, reveal a task and sync the estimate back without leaving the editor. Estimates still come only from revealed votes — there is no tool that sets a number directly, and none that votes on someone's behalf. See the MCP integration guide.
Getting started
Planning poker with Jira is free in QRetro: no per-seat fee, no game quota, and the integration is not gated behind a plan. Connect Jira in your team settings, then open a game.
