Get answers to common questions about planning poker, agile estimation, and running effective sessions
Planning poker is a consensus-based estimation technique used in agile software development. Team members use cards to estimate the effort required for user stories, promoting discussion and reducing bias.
The ideal team size is 5-9 people. This includes developers, testers, and anyone who will work on the stories. Fewer than 5 may lack diverse perspectives, while more than 9 can become unwieldy.
The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is most popular because it reflects increasing uncertainty in larger estimates. T-shirt sizes (S, M, L, XL) work well for new teams or high-level planning.
Keep sessions to 2 hours maximum. Take breaks every 45-60 minutes to maintain focus. If you need longer, split into multiple sessions.
Story points are a unit of measure for expressing the relative effort required to implement a user story. They consider complexity, effort, and uncertainty, not time.
Story points don't directly convert to time. A 5-point story might take different amounts of time depending on the team member working on it. Focus on relative sizing between stories.
Yes, include all work required to complete the story according to your definition of done. This typically includes development, testing, code review, and any necessary documentation.
Wide variations indicate different understandings of the story. This is valuable! Discuss the differences, especially between the highest and lowest estimates, then re-estimate.
If discussion isn't resolving differences, consider: splitting the story into smaller pieces, seeking more information from stakeholders, or parking the story for later research.
The Product Owner should present stories and answer questions but typically shouldn't estimate since they don't do the development work. However, practices vary by team.
Include necessary refactoring work in your estimates. If significant technical debt affects multiple stories, consider creating dedicated technical debt stories.
Original estimates should remain unchanged for velocity tracking. If scope changes, create new stories. Use estimation changes as learning opportunities for future planning.
Use digital planning poker tools, video conferencing with cameras on, and maintain extra engagement techniques like frequent check-ins and clear facilitation.
Key features include: real-time synchronization, multiple estimation scales, timer functionality, result export, mobile compatibility, and easy room sharing.
Physical cards work great for co-located teams and can feel more engaging. Digital tools are essential for remote teams and offer additional features like automatic result tracking.
Find overlapping hours that work for everyone, rotate meeting times if needed, or use asynchronous estimation for less critical stories. Record sessions for those who can't attend.
Use facilitation techniques like round-robin questioning, direct questions to quieter members, and time-boxing discussions. Remind the team that all perspectives are valuable.
Don't estimate unclear stories. Instead, add a "spike" story to research and clarify requirements first. Estimation requires sufficient understanding of the work involved.
Track estimation accuracy over time. Look for patterns - are you consistently over or under estimating? Adjust your reference stories and consider external factors affecting your work.
Yes, but pair them with experienced team members initially. Their fresh perspective can be valuable, and participation helps them learn the codebase and team standards.
Velocity is the sum of story points completed in a sprint. Track it over 3-5 sprints to establish a baseline for planning future sprints.
Velocity is a planning tool, not a performance metric. Focus on delivering value, improving quality, and team happiness. Velocity may naturally increase as the team matures.
Don't count partial points in velocity calculations. Either complete the story or don't count it. This maintains the integrity of your velocity measurements.
No, velocity is team-specific. Each team has different skills, technology stacks, and story point calibration. Use velocity only for planning within the same team.
Didn't find what you were looking for? Check out our comprehensive blog articles for detailed guides and best practices.