Planning poker
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. Planning poker is a variation of the Wideband delphi method. It is most commonly used in  agile software development, in particular in Scrum and Extreme Programming. The method was first defined and named by James Grenning in 2002 and later popularized by Mike Cohn in the book "Agile Estimating and Planning", whose company trade marked the term and a digital online tool. 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. Some organizations use standard playing cards of Ace, 2, 3, 5, 8, and king. 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, including open source software with a free demo server available for everyone to use. 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: 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. Benefits. A study by Moløkken-Østvold and Haugen<ref name="doi:10.1109/ASWEC.2007.15"></ref> reported that planning poker provided accurate estimates of programming task completion time, although estimates by any individual developer who entered a task into the task tracker was just as accurate . Tasks discussed during planning poker rounds took longer to complete than those not discussed and included more code deletions, suggesting that planning poker caused more attention to code quality. Planning poker was considered by the study participants to be effective at facilitating team coordination and discussion of implementation strategies.