Planning poker

Last updated June 13, 2024

Planning poker decks

Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used for timeboxing in Agile principles . In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

Process

Rationale

The reason to use planning poker is to avoid the influence of the other participants. If a number is spoken, it can sound like a suggestion and influence the other participants' sizing. Planning poker should force people to think independently and propose their numbers simultaneously. This is accomplished by requiring that all participants show their cards at the same time.

Equipment

Planning poker is based on a list of features to be delivered, several copies of a deck of cards, and optionally, an egg timer that can be used to limit time spent in discussion of each item.

The feature list, often a list of user stories, describes some software that needs to be developed.

The cards in the deck have numbers on them. A typical deck has cards showing the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks use similar progressions with a fixed ratio between each value such as 1, 2, 4, 8, etc.

The reason for using the Fibonacci sequence instead of simply doubling each subsequent value is because estimating a task as exactly double the effort as another task is misleadingly precise. A task that is about twice as much effort as a 5, has to be evaluated as either a bit less than double (8) or a bit more than double (13).

Several commercially available decks use the sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and optionally a ? (unsure), an infinity symbol (this task cannot be completed), and a coffee cup (I need a break, and I will make the rest of the team coffee). The reason for not exactly following the Fibonacci sequence after 13 is because someone once said to Mike Cohn "You must be very certain to have estimated that task as 21 instead of 20." Using numbers with only a single digit of precision (except for 13) indicates the uncertainty in the estimation. Alternatively standard playing cards of Ace, 2, 3, 5, 8, and king can be used. Where king means: "this item is too big or too complicated to estimate". "Throwing a king" ends the discussion of the item for the current sprint.

When teams are not in the same geographical locations, collaborative software over the internet can be used as replacement for physical cards. Several web applications and mobile applications exist for the purpose.

Procedure

At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them.

The meeting proceeds as follows:

A Moderator, who will not play, chairs the meeting.
The Product Owner provides a short overview of one user story to be estimated. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. A summary of the discussion is recorded, e.g. by the Moderator.
Each individual lays a card face down representing their estimate for the story. Units used vary - they can be days duration, ideal days, t-shirt sizes^[5] or story points. During the discussion, estimations must not be mentioned at all in relation to feature size to avoid anchoring.
Everyone calls their cards simultaneously by turning them over.
People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then the discussion continues.
Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the "consensus vote", although the Moderator can negotiate the consensus.
To ensure that discussion is structured; the Moderator or the Product Owner may at any point turn over the egg timer and when it runs out all discussion must cease and another round of poker is played. The structure in the conversation is re-introduced by the soapboxes.

The cards are numbered as they are to account for the fact that the longer an estimate is, the more uncertainty it contains. Thus, if a developer wants to play a 6 he is forced to reconsider and either work through that some of the perceived uncertainty does not exist and play a 5, or accept a conservative estimate accounting for the uncertainty and play an 8.

Related Research Articles

Cheating in poker is any behavior outside the rules of poker that is intended to give an unfair advantage to one or more players.

Agile software development is the mindset for developing software that derives from values agreed upon by The Agile Alliance, a group of 17 software practitioners in 2001. As documented in their Manifesto for Agile Software Development the practitioners value:

In agile principles, timeboxing allocates a maximum unit of time to an activity, called a timebox, within which a planned activity takes place. It is used by agile principles-based project management approaches and for personal time management.

Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations.

In computing, a scenario is a narrative of foreseeable interactions of user roles and the technical system, which usually includes computer hardware and software.

In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index cards, Post-it notes, or digitally in specific management software. Depending on the product, user stories may be written by different stakeholders like client, user, manager, or development team.

The Wideband Delphi estimation method is a consensus-based technique for estimating effort. It derives from the Delphi method which was developed in the 1950-1960s at the RAND Corporation as a forecasting tool. It has since been adapted across many industries to estimate many kinds of tasks, ranging from statistical data collection results to sales and marketing forecasts. According to the Project Management Institute, Wideband Delphi is an "estimating method in which subject matter experts go through multiple rounds of producing estimates individually, with a team discussion after each round, until a consensus is achieved."

Big design up front (BDUF) is a software development approach in which the program's design is to be completed and perfected before that program's implementation is started. It is often associated with the waterfall model of software development.

Extreme programming (XP) is an agile software development methodology used to implement software systems. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

Scrum is an agile team collaboration framework commonly used in software development and other industries.

In project management, the cone of uncertainty describes the evolution of the amount of best case uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease, reaching 0% when all residual risk has been terminated or transferred. This usually happens by the end of the project i.e. by transferring the responsibilities to a separate maintenance group.

LiquidPlanner, Inc. is a company that develops online project management software.

A glossary of terms relating to project management and consulting.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

The INVEST mnemonic for Agile software development projects was created by Bill Wake as a reminder of the characteristics of a good quality Product Backlog Item or PBI for short. Such PBIs may be used in a Scrum backlog, Kanban board or XP project.

Mike Cohn is one of the contributors to the Scrum software development method. He is one of the founders of the Scrum Alliance.

A programming team is a team of people who develop or maintain computer software. They may be organised in numerous ways, but the egoless programming team and chief programmer team have been common structures.

Velocity is a metric for work done, which is often used in agile software development.

A kanban board is one of the tools that can be used to implement kanban to manage work at a personal or organizational level.

Scrumban is an Agile aligned approach to product delivery which is a hybrid of Scrum and Kanban. Scrumban was originally designed as a way to transition from Scrum to Kanban.

References

↑ "Wingman Software | Planning Poker - The Original Paper". wingman-sw.com. Retrieved 5 July 2017.
↑ Cohn, Mike (November 2005). "Agile Estimating and Planning". Mountain Goat Software. Retrieved 1 February 2008.
↑ "Planning Poker - Trademark, Service Mark #3473287". Trademark Status & Document Retrieval (TSDR). 15 January 2008. Retrieved 26 May 2014.
↑ Cohn, Mike. "Planning Poker Cards: Effective Agile Planning and Estimation". Mountain Goat Software. Mountain Goat Software. Retrieved 30 March 2016.
↑ "How I use T-Shirt sizing as a Product Owner to estimate delivery". Medium. 7 February 2020. Retrieved 22 October 2022.

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] "Wingman Software | Planning Poker - The Original Paper". wingman-sw.com. Retrieved 5 July 2017.

[2] Cohn, Mike (November 2005). "Agile Estimating and Planning". Mountain Goat Software. Retrieved 1 February 2008.

[3] "Planning Poker - Trademark, Service Mark #3473287". Trademark Status & Document Retrieval (TSDR). 15 January 2008. Retrieved 26 May 2014.

[4] Cohn, Mike. "Planning Poker Cards: Effective Agile Planning and Estimation". Mountain Goat Software. Mountain Goat Software. Retrieved 30 March 2016.

[5] "How I use T-Shirt sizing as a Product Owner to estimate delivery". Medium. 7 February 2020. Retrieved 22 October 2022.

[1]

[2]

[3]

[4]

[5]