Free Online Planning Poker for Agile Teams

What is Planning Poker?

Planning Poker, also known as Scrum Poker, is a consensus-based agile estimation technique used by development teams to estimate the effort or relative size of user stories in software development. The technique was first defined and named by James Grenning in 2002 and later popularized by Mike Cohn in his book "Agile Estimating and Planning."

In Planning Poker, team members make estimates by playing numbered cards face-down on the table, instead of speaking them aloud. The cards are revealed simultaneously, and the estimates are then discussed. This approach prevents the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

How to Make Story Estimations Successful

Successful story estimation requires preparation, participation, and practice. Here are key strategies to ensure your planning poker sessions are productive:

• Prepare user stories in advance: Ensure all stories are well-defined with clear acceptance criteria before the estimation session.
• Include the whole team: Developers, testers, designers, and product owners should all participate to get diverse perspectives.
• Use relative estimation: Compare stories to each other rather than trying to estimate absolute time or effort.
• Discuss outliers: When estimates vary significantly, have the highest and lowest estimators explain their reasoning.
• Time-box discussions: Set a timer to keep conversations focused and prevent analysis paralysis.
• Re-estimate if needed: After discussion, team members can change their estimates based on new information.

Understanding Story Points

Story points are a unit of measure for expressing the overall effort required to fully implement a user story. Unlike hours or days, story points represent a combination of complexity, effort, and uncertainty. This makes them more reliable for long-term planning because they're less affected by individual developer speed or interruptions.

The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.) is commonly used for story points because it reflects the inherent uncertainty in estimating larger items. The gaps between numbers grow larger as the numbers increase, acknowledging that our estimates become less precise for bigger stories.

A story worth 1 point might be a simple text change, while a 13-point story could involve multiple components, database changes, and complex business logic. Teams develop their own baseline over time, making story points a relative measure specific to each team.

Why Use the Fibonacci Sequence for Estimation?

The Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89) is the most popular scale for planning poker because it naturally reflects the uncertainty and complexity of software development:

• Increasing gaps: The larger the story, the more uncertainty exists, and the Fibonacci gaps reflect this reality.
• Prevents false precision: You can't estimate a story as 7 points, forcing you to choose between 5 or 8, which is more realistic.
• Encourages breaking down large stories: When a story is estimated at 21 or higher, it signals that it should be split into smaller, more manageable pieces.
• Natural human perception: Research shows humans are better at estimating relative differences when numbers are spaced further apart.

Planning Poker Best Practices

Follow these best practices to get the most value from your planning poker sessions:

• Establish a baseline: Start by estimating a few well-understood stories to establish reference points for the team.
• Focus on relative sizing: Don't worry about absolute accuracy; focus on whether Story A is bigger or smaller than Story B.
• Avoid averaging: If estimates vary widely, discuss and re-vote rather than simply averaging the numbers.
• Use confidence levels: Allow team members to indicate their confidence in their estimates to surface uncertainty.
• Keep sessions short: Limit planning poker sessions to 1-2 hours to maintain focus and energy.
• Review and refine: After sprints, review your estimates versus actual effort to improve future estimation accuracy.

Planning Poker for Remote and Distributed Teams

Online planning poker tools like PokerPlan are essential for remote agile teams. They provide the same benefits as physical cards while adding features that enhance remote collaboration:

• Simultaneous voting: Everyone votes at the same time, preventing anchoring bias even across time zones.
• Real-time synchronization: All participants see updates instantly, creating a shared experience.
• Easy sharing: Simply share a link to invite team members, no software installation required.
• Automatic result calculation: The tool instantly shows consensus, average, and median estimates.
• Session history: Track multiple estimation rounds in a single session for better sprint planning.

Common Planning Poker Mistakes to Avoid

• Estimating in hours instead of points: Story points are about relative complexity, not time. Avoid converting points to hours.
• Letting senior developers dominate: Every team member's perspective is valuable. Encourage junior developers to share their estimates.
• Skipping the discussion: The conversation about why estimates differ is often more valuable than the final number.
• Estimating too many stories at once: Quality over quantity. It's better to thoroughly estimate fewer stories.
• Not breaking down large stories: Stories estimated at 21+ points should be split into smaller, more manageable pieces.
• Comparing velocity across teams: Story points are team-specific. Never compare velocity between different teams.