Planning Poker & Agile Estimation Glossary

Planning Poker (also known as Scrum Poker) is a consensus-based estimation technique used in Agile software development. Team members use physical or digital cards with numbers representing story points or effort estimates. Each member privately selects a card, and when revealed simultaneously, the team discusses discrepancies to reach a consensus on the estimate. This technique helps prevent anchoring bias and encourages team discussion about the work involved.

A Story Point is a unit of measure used in Agile project management to express the overall effort required to fully implement a product backlog item or any other piece of work. Unlike time-based estimates (hours or days), story points represent relative complexity, effort, and risk. A story point is a relative measure, meaning a task estimated as 2 story points should be twice as complex, effort-intensive, or risky as a task estimated as 1 story point. Teams often use the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) or modified Fibonacci sequence for story point estimation.

Velocity is a metric in Agile project management that measures the amount of work a team can complete during a single sprint or iteration. It's typically calculated by summing the story points of all completed user stories or product backlog items in a sprint. Velocity helps teams predict how much work they can accomplish in future sprints and enables more accurate sprint planning. Velocity is team-specific and should not be compared between teams, as it reflects each team's unique capacity and estimation scale.

The Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89...) is commonly used in Planning Poker and Agile estimation because it reflects the uncertainty in larger estimates. As estimates grow, the gaps between numbers increase, which aligns with the reality that larger tasks are harder to estimate precisely. Many teams use a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) or even custom sequences like T-shirt sizes (XS, S, M, L, XL). The Fibonacci sequence helps teams avoid false precision and acknowledges that estimates become less accurate as they increase.

Affinity Estimation is a collaborative Agile estimation technique where team members group user stories or tasks by relative size without assigning specific numbers. The team silently places items on a wall or board, arranging them from smallest to largest. Items are discussed and moved until the team reaches consensus on the relative ordering. This method is useful for initial backlog refinement and helps teams quickly estimate large numbers of items. It's often followed by more precise estimation techniques like Planning Poker for critical items.

A Planning Poker Observer is a non-voting participant in a Planning Poker session who watches the estimation process but doesn't cast votes. Observers might be stakeholders, product managers, or team members who want to learn about the process without influencing the estimates. Some Planning Poker tools allow observers to view real-time voting without revealing their identity to voting participants. This role is useful for transparency and knowledge sharing while maintaining the integrity of the estimation process.

The Coffee Card (often represented as ☕ or a coffee cup icon) in Planning Poker is used when a team member needs a break, feels unclear about the requirements, or believes they cannot provide a meaningful estimate at that moment. It's essentially a "pass" or "I need more information" card that signals to the team that discussion is needed before estimation can proceed. This card helps teams identify when requirements are unclear and prevents rushed or uninformed estimates.

The Question Card (often represented as ❓ or a question mark) in Planning Poker is used when a team member has questions about the user story or task being estimated. It signals that clarification is needed before an estimate can be provided. This card encourages teams to discuss requirements and assumptions, leading to better understanding and more accurate estimates. It's different from the Coffee Card, which typically indicates a break is needed rather than a specific question.

A Sprint (also called an Iteration) is a fixed-length time-boxed period during which a Scrum team works to complete a set amount of work. Sprints typically last 1-4 weeks, with 2 weeks being the most common. During a sprint, the team commits to completing specific user stories or product backlog items, holds daily standups, and ends with a sprint review and retrospective. Sprints help teams maintain a sustainable pace and provide regular opportunities for inspection and adaptation.

Sprint Planning is a Scrum ceremony where the team determines what work will be accomplished during the upcoming sprint. The team reviews the product backlog, selects items they can commit to completing, and breaks down larger items into smaller tasks if needed. Planning Poker is commonly used during sprint planning to estimate user stories. The output of sprint planning is a sprint goal and a sprint backlog containing the selected items and tasks.

The Product Backlog is an ordered list of everything that might be needed in the product, maintained by the Product Owner. It's a living document that evolves as the product and business environment change. Items in the product backlog are prioritized with the most valuable items at the top. The product backlog contains user stories, features, bugs, technical work, and knowledge acquisition activities. Estimation techniques like Planning Poker help determine the size of backlog items.

A User Story is a simple, informal description of a software feature written from the perspective of the end user. It typically follows the format: "As a [type of user], I want [an action] so that [a benefit/value]." User stories are the primary way of capturing requirements in Agile development and serve as the basis for estimation in Planning Poker. They're meant to be small enough to be completed in a single sprint and large enough to deliver value to users.

Scrum is an Agile framework for developing, delivering, and sustaining complex products. It provides a structure for teams to work together effectively through defined roles (Product Owner, Scrum Master, Development Team), ceremonies (Sprint Planning, Daily Standup, Sprint Review, Retrospective), and artifacts (Product Backlog, Sprint Backlog, Increment). Planning Poker is commonly used within Scrum for estimating product backlog items during sprint planning and backlog refinement.

Agile Estimation refers to the practice of estimating the effort, complexity, or size of work items in Agile software development. Unlike traditional estimation that focuses on time (hours or days), Agile estimation typically uses relative sizing techniques like story points, T-shirt sizes, or Planning Poker. The goal is to make reasonably accurate predictions about capacity and delivery timelines while acknowledging uncertainty. Common Agile estimation techniques include Planning Poker, Affinity Estimation, Bucket System, and Dot Voting.

T-Shirt Sizing is an Agile estimation technique that uses relative sizes (XS, S, M, L, XL, XXL) instead of numbers to estimate work items. This approach is intuitive and less intimidating than numeric estimation, making it useful for initial rough estimates or when working with non-technical stakeholders. T-shirt sizes are often later converted to story points for velocity tracking. This technique works well for Affinity Estimation sessions and is a good starting point before using more precise techniques like Planning Poker.

A Burndown Chart is a visual tool used in Agile project management to track the progress of work remaining in a sprint or release. The chart shows time on the horizontal axis and work remaining (often in story points) on the vertical axis. An ideal burndown line shows steady progress toward zero remaining work. Actual progress is plotted daily, and comparing the actual line to the ideal line helps teams identify if they're on track to complete sprint goals. Burndown charts complement velocity metrics in tracking team performance.

The Scrum Master is a servant-leader for the Scrum team who helps ensure the team follows Scrum practices, removes impediments, and facilitates Scrum ceremonies. In Planning Poker sessions, the Scrum Master often facilitates the discussion, ensures all team members participate, and helps resolve disagreements. The Scrum Master is responsible for protecting the team from outside distractions and helping maintain focus during estimation and sprint execution.

The Product Owner is responsible for maximizing the value of the product resulting from the work of the Scrum team. They manage the product backlog, prioritize items, and clarify requirements. During Planning Poker sessions, the Product Owner presents user stories, answers questions about requirements, and accepts estimates. However, the Product Owner typically doesn't vote in Planning Poker to avoid influencing the development team's estimates. Their role is to clarify requirements, not to estimate.

Anchoring Bias is a cognitive bias where individuals rely too heavily on the first piece of information (the "anchor") when making decisions. In estimation, this can occur if someone states their estimate first, influencing others to adjust their estimates toward that number. Planning Poker helps mitigate anchoring bias by having all team members select and reveal their estimates simultaneously, preventing early estimates from influencing others. This is one of the key benefits of using Planning Poker over sequential estimation methods.

Wideband Delphi is an estimation technique that Planning Poker is based on. It involves multiple rounds of anonymous estimation followed by discussion, with the goal of reaching consensus. Planning Poker simplifies Wideband Delphi by using cards with pre-determined values (like Fibonacci numbers) instead of free-form estimates. The technique was developed by Barry Boehm and refined to be more collaborative and less time-consuming than the original Delphi method, making it practical for Agile teams.