What is the facilitator's role in planning poker?
I've been asked to facilitate our planning poker sessions going forward. I've participated as a developer before, but I'm not sure what I should be doing beyond reading the user stories aloud.
Our current sessions feel chaotic - people talk over each other, our senior dev tends to dominate discussions, and sometimes people forget to vote.
What makes a good planning poker facilitator? What specific things should I be doing to keep things running smoothly?
Great facilitators make planning poker look effortless. Here's your complete playbook:
Before the Session
- Review stories with product owner - catch ambiguities early
- Ensure everyone has planning poker cards (physical or digital)
- Set up screen sharing if remote
- Book 90-120 minutes max (attention spans drop after that)
Core Facilitation Responsibilities
1. Time Management
- Read story aloud (or have PO do it)
- Allow 2-3 minutes for questions
- Call for vote: "Everyone ready? Show cards on 3..."
- Time-box discussion to 5 minutes max
- If no consensus after 2 rounds, take higher estimate and move on
2. Ensure Everyone Participates
- Call out non-voters: "Sarah, I didn't see your card - what's your estimate?"
- Prevent domination: If senior dev always speaks first, ask junior devs first intentionally
- Balance voices: "We've heard from frontend team, what does backend think?"
3. Facilitate Discussion (Not Participate)
- You DON'T vote (unless team agrees facilitator votes)
- You DON'T argue for estimates
- You DO ask clarifying questions: "Can you explain what you mean by that?"
- You DO surface disagreements: "I see 3 votes for 5 and 3 for 13 - let's hear both perspectives"
4. Keep Discussions Productive
Watch for discussion anti-patterns:
- Bikeshedding: "We're debating implementation details, not complexity. Let's focus on the estimate."
- Scope creep: "That sounds like a separate story. Let's estimate this one as-is."
- Solution design: "We don't need to solve it now, just estimate the complexity."
5. Capture Information
As facilitator, you're documenting:
- Assumptions made during estimation
- Dependencies identified
- Questions that need PO follow-up
- Stories that need splitting
Handling Common Situations
Silence after reveal: "I see we have a spread from 3 to 13. Let's hear from both ends - why 3? Why 13?"
One person dominates: "Thanks John. Before we continue, I'd like to hear from others who haven't spoken yet."
Discussion going long: "We're at 7 minutes. Let's do one more quick round of voting, then decide."
Your Energy Matters
As facilitator, you set the tone:
- Keep energy high (especially after lunch)
- Take 10-minute breaks every hour
- Celebrate quick consensus: "Nice! That was fast - everyone saw it the same way."
- End on time even if you don't finish all stories
One thing I do: keep a "parking lot" for off-topic discussions. When someone brings up implementation details or architectural debates, I write it down and say "Let's discuss that after planning."
This acknowledges their concern without derailing the session. 90% of the time people forget about it anyway - it was just thinking out loud.
This is super helpful! I especially like the idea of asking junior devs first to prevent senior dev domination. I'll try the parking lot technique too.
Thanks for the detailed breakdown!
Also: rotate the facilitator role every sprint. This prevents facilitator fatigue and ensures everyone learns the skill.
The person facilitating can't participate in the estimates fully, so rotation keeps it fair.