How to Run Your First Planning Poker Session

Planning Poker is one of those things that sounds complicated until you actually do it — then it feels obvious. The whole session takes under an hour for most teams, requires no preparation beyond having a backlog, and produces estimates the team actually believes in because everyone arrived at them together.

This guide walks you through a complete session from scratch using TasksTally: creating the room, inviting your team, running the voting rounds, and wrapping up. No account needed, no downloads, no configuration. Just a link and five minutes.

🎭 The Two Roles: Host and Guest

Every TasksTally session has one host and one or more guests. The host controls the session flow — when voting starts, when results are revealed, and when the session ends. Guests vote each round and follow the host's lead.

If the host leaves mid-session, their role is automatically transferred to another participant so the session can continue.

🛠️ Before You Start

You don't need much — but having these things ready makes the session run smoothly:

• A backlog of items to estimate. These can be user stories, tasks, bugs — anything the team needs to size. For Jira users, TasksTally imports issues directly from an active sprint, so your backlog is already there.
• The right people in the room. Estimation works best when everyone who will touch the work is present: developers, QA, designers, and ideally the product owner to answer scope questions. Missing stakeholders are the most common cause of wildly divergent votes.
• Agreement on the voting scale. Fibonacci (1, 2, 3, 5, 8, 13…) is the most common choice for story points. T-shirt sizing (XS, S, M, L, XL, XXL) works well for teams that prefer relative buckets over numbers. Decide before the session starts — switching mid-session is disorienting.

🚀 Step 1: Create the Session

The host goes to Start Planning and fills out the setup form:

1. Planning type. Choose Basic for a free-form session where you discuss tasks verbally during the call, or Jira to connect your Atlassian account and import issues from an active sprint directly into the session.
2. Voting scale. Select Fibonacci or T-shirt sizing. This determines which cards appear during voting.
3. Planning name. Give the session a name your team will recognise — typically the sprint name or date. If you connected Jira and selected a sprint, this is pre-filled automatically.
4. Your name. How you'll appear to other participants in the room.
5. Host voting. By default, the host is expected to vote each round. If you want to act purely as a facilitator — reading stories aloud and managing the discussion without submitting your own estimate — uncheck The host is required to vote. This means the reveal won't wait for you.

Hit Start planning and you land in the planning room.

🔗 Step 2: Invite Your Team

Inside the planning room, you'll see a Copy invite link button in the top-right corner. That link is everything your teammates need — paste it into your team chat (Slack, Teams, Discord) or drop it in the video call chat.

When a teammate opens the link they see the planning name (pre-filled, read-only) and a field to enter their name. One click and they're in. No account, no email, no waiting for an invitation to be "accepted".

As guests join you'll see them appear in the room. The Start planning button becomes active as soon as at least one guest is present.

🗳️ Step 3: Run the Voting Rounds

Each round follows the same pattern:

1. Present the story. Read the task aloud (or, in Jira mode, it's displayed in the left sidebar for everyone to see). Answer any quick clarifying questions — but don't let discussion go longer than a minute before voting. The point is to surface assumptions through the votes, not before them.
2. Everyone votes privately. Each participant selects a card. Votes are hidden — nobody can see anyone else's selection until the round closes. This prevents anchoring, where an early number skews the rest of the group toward it.
3. The reveal happens automatically. As soon as the last participant submits their vote, all cards flip at once. No host action needed.
4. Discuss the outliers. Ask the person who voted highest and the person who voted lowest to explain their reasoning. Do not ask everyone — this keeps the discussion tight and reveals the real disagreement quickly.
5. Re-estimate or accept. If the discussion changed the team's thinking, the host clicks Re-estimate to run another round on the same story. If the team has converged, move on.

For Jira sessions, the host clicks Vote next task to advance through the sprint issues one by one. The right sidebar shows all issues in the sprint with their current status — estimated, skipped, or pending.

⏭️ Skipping Tasks (Jira Mode)

Sometimes a story isn't ready to be estimated — the acceptance criteria are missing, there's a dependency that needs resolving first, or the team simply doesn't have enough context. In Jira mode, the host can click Skip task during the voting phase to move on without forcing a number.

Skipped issues are marked in the sidebar and excluded from the final count. The host can re-enable a skipped issue from the sidebar if the team circles back.

A good rule of thumb: if two minutes of discussion hasn't produced enough clarity to vote, skip the story and return to it at the next refinement session rather than forcing a low-confidence estimate.

🏁 Step 4: End the Session

When the team has worked through the backlog, the host clicks End planning. For Jira sessions, TasksTally shows a summary — how many issues were estimated versus skipped — before closing out.

If there are unestimated issues remaining, you'll see a list of them in the confirmation modal. You can still end the session — that list is just a final checkpoint before wrapping up.

💡 Tips for a Smooth First Session

• Time-box each story to two minutes of discussion. If the team is still talking after two minutes, the story isn't ready. Skip it or flag it for refinement.
• Use a reference story. Before starting, agree on a task the whole team remembers as a "medium" effort — something that felt like a 5. All other estimates are relative to it. This dramatically reduces variance caused by people using different baselines.
• Don't average the votes. If votes are split, the answer isn't the midpoint — it's that the team has unresolved questions. Surface the question, address it, then re-vote.
• Accept the higher estimate when genuinely unsure. Optimism is the single most common cause of missed sprint commitments. When the team is split and discussion hasn't resolved it, default to the higher number.
• Keep sessions under 90 minutes. Estimation fatigue is real. If your backlog requires more than 90 minutes to estimate, split it across two sessions.

🏁 Conclusion

Your first Planning Poker session will probably feel a bit rough around the edges — discussions will go long, someone will ask what "8 points" means, and you might need to re-estimate a few stories. That's completely normal.

What you'll also notice: the team talks about the work in a way they probably didn't before. Hidden assumptions surface. Scope gets clarified. Someone flags a dependency nobody else knew about. That conversation is the real output of a Planning Poker session — the numbers are just a record of what the team agreed on after having it.

By the third or fourth sprint, the sessions will be faster, the estimates will be more consistent, and your team will have built a shared vocabulary for what "small", "medium", and "large" actually mean for your specific codebase and team.

🤓 Learning Resources

📚 Related Articles