Planning poker exists for one reason: to stop the first number said out loud from becoming everybody's number. Each person commits to an estimate before seeing anyone else's, and the interesting part is the disagreement that follows.
None of that requires a meeting. It requires that votes stay hidden until they are revealed, and that somebody looks at the spread before a number is saved. This guide covers how to do that asynchronously in Jira, and one Jira detail that quietly breaks a lot of estimation setups.
When async estimation works, and when it doesn't
| Situation | Async or live? |
|---|---|
| Well-written stories the team broadly understands | Async. Most issues converge on the first round, and nobody needed to be in a room for that. |
| A team spread across time zones | Async, almost by definition. A refinement call at 8am for half the team and 6pm for the other half is a meeting nobody estimates well in. |
| New, vague or risky work | Live. The value is in the conversation about why one person said 3 and another said 13, and that conversation is slower in comments. |
| A new team | Live for the first few sprints, until people share a sense of what a "5" is. |
Most teams end up mixing the two: estimate the straightforward half of the backlog asynchronously during the week, and spend the refinement meeting only on the issues where the votes disagreed.
A simple way to run it
- Pick the issues. The top of the backlog, or the next sprint's candidates. Ten to twenty is a good batch; more than that and people vote carelessly on the last ones.
- Set a window. "Vote on these by Thursday midday." Without a deadline, async estimation drifts into never.
- Vote privately. Everyone picks a card on each issue. Nobody sees anybody else's card until the reveal, and it should be possible to see who has voted without seeing what they voted.
- Reveal when enough people have voted. Anyone can do it once the people who know the area have voted; waiting for literally everyone is how async estimation stalls.
- Save when the votes agree. If the spread is within one card, take the consensus or the higher value and move on.
- Discuss when they don't. A spread of 3 to 13 is not a number to average. It means two people understood the issue differently. Park it for the live session, or ask the outliers to leave a comment explaining their card, then vote again.
Two cards worth keeping: a "?" for "I don't know enough to estimate this", and a coffee cup for "this needs a conversation". Neither should ever be saved as an estimate. A lot of "?" votes on one issue is a signal about the issue, not about the team.
Why estimates sometimes never show up on the board
This is the Jira detail that catches teams out, and it is not obvious from the interface.
Jira Cloud has two different story point fields. Which one a board reads depends on the kind of project:
| Project type | Field the board usually estimates in |
|---|---|
| Team-managed | Story point estimate |
| Company-managed (Scrum) | Story Points |
They are separate custom fields with separate values. If a tool, an automation rule or a CSV import writes to Story Points in a team-managed project, the value is stored somewhere and the board simply doesn't show it. Velocity charts and sprint commitments then add up to zero, and nobody knows why.
We measured this on a test site with one project of each kind: the board configuration of each pointed at a different field, and writing to the other one produced a value the board ignored.
How to check which field your board uses
- Company-managed board: Board → Board settings → Estimation. The statistic shown there (Story Points, Original time estimate, or another field) is the one the board sums.
- Team-managed project: the estimation setting lives in the project's features and settings; the field is Story point estimate unless the project estimates in time.
- Any tool that writes estimates should tell you which field it writes to. If it doesn't, write an estimate with it and check that the issue card on the board shows it.
Time-based estimation adds one more wrinkle: Original estimate belongs to time tracking, and it only appears if time tracking is enabled for the project.
What to look for in a tool
You can run async planning poker with nothing more than comments and discipline: everyone posts their card in a private message to the facilitator, who reveals them together. It works for a small team. If you use an app instead, including ours, these are the questions worth asking:
- Are votes hidden until the reveal, including from administrators and from the app's own logs?
- Can people vote from the issue itself, whenever they get to it, rather than only inside a scheduled session?
- Which field does it write to, and does it detect the one your board uses?
- Does it confirm the save? "Saved" should mean the value was read back from Jira, not that a request was sent.
- Where does the data go? Some estimation tools run on the vendor's own servers. Whether that matters depends on your security review.
Estimation for Jira, our app, is built around those answers: votes cast from the issue or in a live session, hidden until someone reveals them, and the agreed estimate written to the field your board actually uses, then read back to confirm it. It runs entirely on Atlassian infrastructure. It is currently in Atlassian Marketplace review.
One caveat
Estimates are a planning aid, not a performance measure. The moment story points are used to compare people or teams, they inflate, and no estimation technique survives that. Async or live, the point is a shared understanding of the work.