A planning poker tool helps agile teams estimate backlog stories by collecting hidden Fibonacci story point votes, comparing the spread, and turning consensus into sprint planning estimates.
backlog items
13 total points
close or accepted
Select a backlog item, add each revealed vote, then review the suggested story point estimate.
4 votes from Participant and team
Use consensus status to decide what is ready for sprint planning and what needs another discussion round.
| Story | Votes | Median | Suggested | Status | |
|---|---|---|---|---|---|
| Invite teammates to a feedback board | 3, 3, 5, 3 | 3 | 3 | Consensus | |
| Add Slack notifications for new feature requests | 8, 13, 8, 13 | 10.5 | 8 | Close | |
| Export roadmap ideas to CSV | 2, 3, 2 | 2 | 2 | Consensus |
Accept estimates when votes are tight. When the spread is high, discuss assumptions, split the story if needed, and run one more vote before committing it to the sprint.
List the backlog items your team needs to estimate for the next sprint.
Have each teammate choose a Fibonacci story point card without anchoring others.
Add the revealed votes and review median, average, spread, and suggested estimate.
If votes are far apart, compare assumptions and clarify hidden work or risks.
Copy Markdown or download CSV estimates for sprint planning notes.
Common questions about scrum poker, Fibonacci story points, and agile sprint estimation.
Planning poker is an agile estimation technique where each team member privately picks a story point card, then the group reveals votes together and discusses large differences. It reduces anchoring and helps teams estimate backlog items more consistently.
Story points are relative estimates of size, complexity, and risk. A 5-point story should feel larger than a 3-point story and smaller than an 8-point story. Teams usually use Fibonacci values because uncertainty grows as work gets larger.
A practical consensus rule is to accept estimates when most votes are within one or two Fibonacci cards. If the spread is larger, ask the highest and lowest voters to explain their reasoning, then vote again.
Planning poker should estimate relative complexity, not exact time. Time estimates create false precision. Story points work better for sprint planning because velocity can convert relative estimates into capacity over several sprints.
Re-vote when votes are widely split, hidden requirements appear, or the team changes the scope of the story during discussion. The second vote is usually more reliable because everyone has heard the main risks and assumptions.
More lightweight tools from FeatureVote for product prioritization and roadmap decisions.
Score features by Reach, Impact, Confidence, and Effort and export a ranked roadmap.
Open toolPlot product features on an impact vs effort matrix to find quick wins and big bets.
Open toolTurn a feature list into a quarter-based product roadmap with priorities.
Open toolBuild NPS, CSAT, CES, and PMF surveys from proven question templates.
Open toolAfter your team estimates work, use FeatureVote to collect customer votes and keep roadmap priorities grounded in real user demand.