If you're a Scrum Master, product owner, developer, or team lead working with Hindi-speaking teams, this planning poker tutorial hindi is written for you. I combine practical experience running dozens of planning sessions with clear, step-by-step guidance so your next sprint planning becomes faster, fairer, and more accurate.
What is Planning Poker and why it works
Planning Poker (also called Scrum Poker) is a collaborative estimation technique where team members privately select a card that represents their estimate for the effort or complexity of a user story, then reveal simultaneously. It balances the influence of seniority, encourages discussion, and helps teams reach a consensus quickly.
Think of it like a family deciding how long a road trip will take: each person has a different perspective (traffic knowledge, driving speed, stops). If everyone shouts a number, the loudest voice wins. In Planning Poker everyone reveals at the same time — you get diverse inputs without anchor bias and then focus discussion on the differences.
When to use Planning Poker
- During sprint planning to estimate story points or relative size.
- When a team is forming or has many new members to build shared understanding.
- When tasks are uncertain, complex, or require cross-functional discussion.
Roles and preparation
Clear roles make the session productive:
- Product Owner (PO): presents the user story, acceptance criteria, and priority.
- Scrum Master / Facilitator: keeps the timer, enforces rules, and resolves process issues.
- Development Team: provides estimates — includes developers, QA, designers as appropriate.
Preparation checklist:
- Stories in the backlog should be small enough (ideally 1–2 days to 1–2 weeks depending on your sprint length).
- Acceptance criteria and any relevant designs or mockups shared beforehand.
- Choose a scale (Fibonacci 1,2,3,5,8,13 or modified: 0.5,1,2,3,5,8,13,20,40,100).
- Decide if you’ll estimate in story points, ideal days, or T-shirt sizes. Story points are most common.
The step-by-step Planning Poker flow
- PO reads the story: The Product Owner (or a proxy) briefly describes the story, acceptance criteria, and any constraints. Keep it short—clarifying questions can come after.
- Ask clarifying questions: Team asks questions to uncover hidden work (integration, data migration, security). PO answers; product decisions may be deferred if not relevant to estimation.
- Private estimation: Each participant selects a card (physical or digital) representing their estimate without revealing it.
- Simultaneous reveal: Everyone reveals at once. This prevents anchoring and lets the team see the distribution of opinions.
- Discuss outliers: If estimates are widely spread, ask the highest and lowest estimators to explain their reasoning. Encourage specifics rather than abstract claims.
- Re-vote: After discussion, vote again. Typically, the range tightens and the team converges on a consensus number.
- Record and move on: Add the agreed estimate to the backlog and continue with the next story.
Example session (real-world)
Story: "As a user, I want to reset my password via email so I can regain account access."
- PO: Acceptance criteria include a reset link emailed, token expiry of 1 hour, and rate limiting for security.
- Initial votes: 2, 5, 8, 13, 5 — wide spread.
- Discussion: Developer A notes integration with an auth microservice is done (reduces work). Developer B highlights that email templates and rate limit infra are new (increases work).
- Second votes: 3, 3, 5, 3 — consensus at 3 story points.
- Outcome: Estimate recorded as 3; PO adds it to the sprint candidate list.
Choosing the right deck and scale
Common options:
- Fibonacci (1,2,3,5,8,13,20,40,100) — good for relative uncertainty.
- T-shirt sizes (XS, S, M, L, XL) — helpful when your team is new to points.
- Modified linear (0.5,1,2,3,5,8,13) — useful when you want more granularity for small items.
Large numbers (40/100) are placeholders for "epic/needs splitting." If a story gets a big number, stop and split it into smaller, estimable pieces.
Facilitating for Hindi-speaking teams
When your team prefers Hindi, mix English technical terms with Hindi explanations to avoid confusion. Examples of useful Hindi phrases:
- "Kya acceptance criteria clear hain?" (Are the acceptance criteria clear?)
- "Konse dependencies hain?" (What dependencies exist?)
- "Yeh story split karna behtar hoga" (It would be better to split this story.)
For remote teams, encourage people to speak in the language they are most comfortable with when explaining their reasoning, then paraphrase in the team's common language to ensure shared understanding.
Remote tools and integrations
Physical cards work well in collocated teams. For distributed or hybrid teams, try these tools:
- Online Planning Poker apps (Scrum Poker, Pointing Poker in Jira, Miro templates).
- Video conferencing + shared board (Miro, MURAL, Google Jamboard).
- Integrated agile tools (Jira, Azure DevOps) for recording estimates immediately.
Common pitfalls and how to avoid them
- Anchoring: One strong opinion shouldn't dominate. Simultaneous reveal prevents this.
- Estimating tasks vs stories: Planning Poker is for relative story sizing, not micro task timeboxing.
- Skipping discussions: If the team always agrees quickly, you might miss hidden complexity. Probe when estimates are too low or too high.
- Confusing velocity with capacity: Story points measure relative effort/complexity, not exact hours. Use velocity trends to plan capacity.
How to handle disagreement
If discussion cycles without consensus, use these strategies:
- Ask for concrete risks that make someone vote higher or lower.
- Temporarily time-box discussion (e.g., 5 minutes), then take a practical decision — either pick a median or split the story.
- If the PO is uncertain about scope, defer decision and flag the story for refinement.
Advanced tips from experience
- Rotate the facilitator so the process improves and the team learns to self-facilitate.
- Keep a "calibration list" — a few well-understood stories with known points to help new members align to team norms.
- Track estimation accuracy over time (predicted vs actual). Use it as a coaching tool, not as punishment.
- For cross-functional work, ensure representatives from all involved disciplines vote (e.g., QA, DevOps, Design).
Sample backlog with estimated story points
- Login page validation corrections — 1
- Password reset via email (example above) — 3
- Implement OAuth SSO integration — 8
- Data migration for user profiles — 13 (split into smaller tasks)
- Performance tuning for search queries — 5
Measuring success
Planning Poker is successful when:
- The team reaches consensus faster, with fewer re-estimates.
- Velocity stabilizes and planning forecasts improve.
- Stories are delivered with fewer surprises in the sprint.
Frequently asked questions (FAQ)
How long should a planning poker session take?
Rough guideline: 5–10 minutes per story, but many teams average 2–4 minutes once they are mature. Keep refinement sessions separate if more discussion is required.
What if a PO wants exact hour estimates?
Story points are for relative sizing; convert to hours only for tasks during sprint planning if your process needs it. Avoid mixing the two during the same discussion.
Should testers estimate?
Yes—include anyone who will deliver the story. Their perspective often catches hidden test and verification work.
Final checklist before your next session
- Stories ready and prioritized.
- Acceptance criteria clear or flagged for refinement.
- All relevant team members invited and pre-reads shared.
- Tools (cards, app, board) set up and tested.
- Timebox for the meeting and per-story debates decided.
If you'd like a compact printable guide to share with your team or a bilingual template to run your first session in Hindi and English, check this curated resource: planning poker tutorial hindi.
About the author
I’m a certified Scrum Master and product practitioner with 8+ years helping teams adopt lightweight estimation practices across fintech and consumer apps. I’ve observed how a well-run planning poker session reduces rework and builds collective ownership — especially in teams where language and cultural norms can make open discussion harder. My approach blends pragmatic facilitation, clear acceptance criteria, and small exercises that surface assumptions quickly.
Closing thoughts
Planning Poker is more than a ceremony; it’s a structured conversation that transfers knowledge, aligns expectations, and reveals unknowns early. For Hindi-speaking teams, blending technical terms with Hindi explanations and creating a safe space for questions improves estimation quality and team cohesion. Start small, calibrate frequently, and treat the process as a continuous improvement activity — not a rigid rule.
