Planning Poker Handbook

Planning Poker, often referred to as Scrum Poker or Pointing Poker, is a highly effective, consensus-based technique used primarily in Agile software development to estimate the effort or relative size of development goals, most commonly user stories. It's a gamified approach that leverages the collective intelligence of the development team to arrive at more accurate and reliable estimates than traditional methods. By involving all team members in the estimation process, it fosters shared understanding, promotes collaboration, and uncovers potential challenges or misunderstandings early on.

Scrum Poker is synonymous with Planning Poker. The term 'Scrum Poker' is frequently used because the technique is most commonly applied within Scrum frameworks for estimating product backlog items, particularly user stories, during sprint planning or backlog refinement sessions. It aligns perfectly with Scrum's principles of transparency, inspection, and adaptation, providing a structured yet flexible way for self-organizing teams to commit to achievable work.

Pointing Poker is another common name for Planning Poker, emphasizing the use of 'story points' as the unit of estimation. Story points are abstract measures of effort, complexity, and risk associated with implementing a user story. Unlike time-based estimates (hours or days), story points encourage teams to think about the relative size of tasks, leading to more consistent and less emotionally charged estimations.

The primary purpose of Planning Poker is to create accurate and reliable estimates for work items within an agile project. It serves several crucial functions: achieving consensus, improving estimation accuracy, promoting shared understanding, enhancing team collaboration, and identifying gaps and risks early in the process.

Planning Poker was invented by James Grenning in 2002. He developed it as an improvement over the traditional Wideband Delphi estimation method, aiming to make the process more engaging, efficient, and collaborative. The technique was later popularized by Mike Cohn through his influential book, 'Agile Estimating and Planning'.

It's called 'poker' because it borrows elements from the card game. Similar to traditional poker, participants are dealt a hand of cards, and they reveal their chosen card simultaneously. This simultaneous reveal prevents anchoring bias, where early estimates might unduly influence later ones. The game-like structure makes the estimation process more interactive and less tedious.

Playing Planning Poker involves a structured, collaborative process: 1) Gather the team (Product Owner, Scrum Master, development team), 2) Present the user story with requirements and acceptance criteria, 3) Silent estimation where each member chooses a card, 4) Simultaneous reveal to prevent anchoring bias, 5) Discussion of discrepancies, with highest and lowest estimates explaining their reasoning, 6) Re-estimation if needed until consensus is reached, 7) Record the agreed estimate.

Core rules include: all team members participate, silent voting to avoid influence, simultaneous reveal, discussion for divergent estimates, no external influence from Product Owner or Scrum Master on estimates, timeboxing to keep sessions focused, and consensus as the ultimate goal.

Sessions should be timeboxed to maintain focus and efficiency. Typically 1-2 hours for sprint planning with moderate stories, or 30-60 minutes for backlog refinement. If sessions run too long, team fatigue reduces estimate accuracy, so it's better to break into multiple shorter sessions.

Large disagreements indicate significant differences in understanding. The facilitator should ask outliers (highest and lowest estimates) to explain their reasoning, facilitate focused discussion to share perspectives, clarify assumptions, and then re-estimate. This iterative process continues until consensus is reached or the story needs to be broken down further.

Planning Poker cards are physical or virtual cards used by team members to cast their estimates. Each card has a numerical value representing story points. Standard decks use a modified Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) and special cards like '?' for uncertainty or a coffee cup for breaks.

The Fibonacci sequence reflects increasing uncertainty as tasks get larger. The larger gaps between higher numbers acknowledge that estimating a 100-point story is much harder than a 3-point story. It discourages false precision, promotes discussion when estimates are far apart, and provides a simple, well-known sequence for teams to adopt.

The '0' card indicates that the user story requires no effort or is already completed. It's used for tasks that are already done, trivial tasks requiring negligible effort, or to indicate the story is so simple it doesn't warrant points.

The '?' card signifies uncertainty or lack of understanding about the user story. When played, it means the team member doesn't have enough information to provide an estimate, prompting further discussion and clarification.

No, you should avoid converting story points to hours. This defeats the purpose of story points, which are designed to be abstract and relative. Converting creates false precision, leads to micro-management, ignores uncertainty, and discourages collaboration. Focus on team velocity (story points completed per sprint) for forecasting instead.

Ideal participants include the entire development team (developers, testers, designers, etc.), the Product Owner (to present stories and answer questions), and the Scrum Master (to facilitate). Other stakeholders can observe but typically don't participate in estimation.

The Product Owner presents user stories clearly, answers questions from the development team, provides context and business value perspective, and prioritizes the backlog. Importantly, they do NOT estimate - that's the development team's responsibility.

The Scrum Master facilitates the session, ensures rules are followed, encourages collaboration, mediates discussions, enforces timeboxes, and protects the team from external pressures. They typically don't vote unless they're actively involved in development work.

Absolutely. All specialists who are part of the development team should participate, including QA engineers, UX/UI designers, database administrators, etc. Their unique perspectives are crucial for identifying all work involved in completing a user story.

Key benefits include improved estimation accuracy through collective wisdom, enhanced team collaboration, shared understanding and ownership, early identification of risks and challenges, increased engagement through gamification, and reduced anchoring bias through simultaneous reveals.

Potential disadvantages include being time-consuming (especially for large backlogs), requiring skilled facilitation, risk of groupthink if not well-facilitated, potential misuse of estimates by stakeholders, and becoming tedious if overused for minor tasks.

Planning Poker may not suit teams that: lack good remote collaboration tools, work with highly predictable/repetitive tasks, follow continuous flow models where formal estimation is less critical, are very small and can reach consensus informally, or operate in cultures not supportive of collaborative estimation.

Common challenges include lengthy discussions, anchoring bias, lack of engagement, misunderstanding of user stories, pressure from stakeholders for low estimates, and inconsistent story point definitions across the team.

Facilitators should actively solicit input from quieter members, use talking tokens in extreme cases, timebox individual contributions, and reinforce the collaborative nature of the process to ensure everyone's knowledge is leveraged.

For new teams: provide training on rules and benefits, establish clear anchor stories for calibration, be patient as teams need several sessions to become proficient, provide strong facilitation, and retrospect after each session to identify improvements.

Alternatives include T-shirt sizing (XS, S, M, L, XL), dot voting, bucket system (affinity estimation), Wideband Delphi, and asynchronous Planning Poker for distributed teams.

T-shirt sizing uses sizes like XS, S, M, L, XL, XXL for relative estimation. It's useful for high-level estimation of large backlogs, early-stage projects with high uncertainty, and quick initial sizing without deep analysis.

Wideband Delphi is a more formal, iterative estimation technique that predates Planning Poker. It involves multiple rounds of anonymous estimation and discussion until estimates converge. Planning Poker is essentially a more gamified and streamlined version of this method.

Popular online tools include scrumjam.app, planningpokeronline.com, scrumpoker.online, planitpoker.com, pointingpoker.com. Jira integrations from Atlassian Marketplace, Azure DevOps extensions, and templates in online whiteboarding tools like Miro and Mural.

Yes, physical cards are the original and still very effective method, especially for co-located teams. The tactile nature can make sessions more engaging. You can purchase pre-made decks or print your own from free templates available online.

Use Jira by installing Planning Poker apps from Atlassian Marketplace for direct integration with your backlog, automatic estimate saving, or use standalone tools and manually transfer information between systems.