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. 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 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.

Online Tools

See also 
 Comparison of scrum software, which generally has support for planning poker, either included or as an optional add-on.
 Fibonacci scale (agile)

References 

Agile software development
Software project management
Software development philosophies
플래닝 포커, 다른 말로 스크럼 포커 라고도 불리는데, 이는 추정을 위한 합의 기반 기술(consensus-based technique)로써 대부분 소프트웨어 개발에 있어서 개발 목표를 위한 공수 산정이나 상대적 규모산정에 사용된다. 플래닝 포커에서 그 그룹의 구성원들은 공수 산정 시에 입으로 크게 말하는 대신에 숫자로된 카드를 테이블에 엎어놓는 방식으로 놀이처럼 진행한다. 그 카드들을 확인 하면서 해당 공수들이 논의된다. 숫자를 숨기는 이런 방식은 구성원들의 편향적인 고정관념을 피할 수 있게 해준다. 누군가 처음 숫자를 크게 말하면서 다음 사람들의 공수 산정에 영향을 미칠 수 있는 것처럼 말이다.

플래닝 포커는 광대역 델파이(Wideband delphi)의 한 형태이다. 이것은 애자일 소프트웨어 개발에서 가장 일반적으로 사용된다. 특히 스크럼 (애자일 개발 프로세스)과 익스트림 프로그래밍 방법론에서 말이다.

이 방법은 2002년 제임스 그레닝(James Grenning)
에 의해서 정의되고 명명된 이후에, 마이크 콘(Mike Cohn)이 저술한 애자일 추정과 계획(Agile Estimating and Planning),
 whose company trade marked the term.
이라는 책으로 인해서 유명해졌다.

프로세스

왜 사용하는가? 

플래닝 포커를 사용하는 이유는 다른 참가자의 영향을 배제하기 위해서이다. 만약 숫자를 말한다면, 그것은 곧 제안처럼 들리고, 그로인해 다른 참석자들의 공수산정에 영향을 미치기 때문이다. 플래닝 포커는 사람들이 독립적으로 사고하고 그 숫자를 동시에 제안하도록 해야 한다. 모든 사람들이 동시에 그들의 카드를 보여주어야만 가능하다.

장치 

플래닝 포커는 고객에게 제공되어야할 기능 리스트들과, 여러 벌의 카드 묶음이 있어야 한다. 그리고 필요하다면, 각 아이템 별로 제한된 시간 내에만 논의할 수 있도록 에그 타이머를 사용할 수도 있다.

기능 리스트, 혹은 유저 스토리는 개발할 소프트웨어에 대한 대략적인 설명이다.

데크에 있는 카드는 숫자로 되어있다. 일반적으로 데크에는 피보나치 숫자가 쓰여있는 카드가 놓인다. 예를 들면 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; 다른 데크에도 유사하게 진행된다. 

피보나치 수열을 사용하는 이유는 큰 아이템의 공수 산정시에 내제된 불확실성을 반영하기 위해서이다.

여러 가지 사용할 수 있는 상용 데크들은 수열을 사용한다. : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, 그리고 경우에 따라 ?(잘 모르겠음) 그리고 커피 컵(나 쉬고 싶어). 어떤 조직에서는 일반 포커 카드를 사용하기도 한다. : 에이스(Ace), 2, 3, 5, 8 그리고 킹(King). 킹의 의미는 "이 아이템은 산정하기에 너무 덩치가 크다, 또는 너무 복잡하다."라는 뜻이다.  킹을 던진다면 이는 "이번 스프린트에서 이 아이템은 논의하지 말자"라는 뜻이다.

스마트폰이 있다면 개발자들에게 물리적인 카드 대신에 앱을 사용하게 할 수도 있다. 팀들이 같은 장소에서 일하지 않는다거나, 협업 소프트웨어를 개발하고 있다면 물리적인 카드를 대신해서 사용할 수 있다.

절차 

공수산정 회의에서 개별 참석자에게는 카드 한 데크가 주어진다. 모든 데크들은 카드의 세트를 구별할 수 있게 되어있다.

회의는 다음 절차를 따른다. :

 중계자가 미팅에 참석하고 공수를 산정하지는 않는다.
 제품 관리자는 간략한 개요를 설명한다. 팀원들은 질문이나 토론을 통하여 애매한 사항이나 위험요소를 확실히 할 기회를 갖는다. 프로젝트 매니저가 토론 내용을 종합 정리한다.
 각 개인은 그들의 산정 결과를 카드로 엎어서 내려놓는다. 단위는 다양하게 사용된다. - 일정기간, 이상적인 일자, 혹인 스토리 포인트가 될 수 있다. 토론하는 동안, 다른 사람의 공수 산정에 영향을 미치는 어떠한 숫자도 말을 하면 안된다.
 모두가 동시에 자신의 카드를 뒤집어 보여준다.
 가장 높은 숫자와 가장 낮은 숫자를 제시한 사람들에게는 비누상자가 주어지고, 왜 그런 산정을 했는지 타당한 이유를 제시하고 토론을 계속 진행한다.
 공수산정 절차를 합의에 도달할때까지 반복한다.  비록 중계자가 합의 사항에 대해서 협상하려 할 지라도 그 개발부분을 담당하게 될 개발자가 제시한 내용이 대부분 반영된다.
 토론이 체계적이게 하려면, 중계자나 프로젝트 관리자는 어떤 시점에 계란 타이머를 뒤집어야 할 것이다. 그리고 시간이 다 되면, 토론은 중지되어야 하고, 포커 카드를 다시 시작해야 한다. 비누 박스들을 다시 주면서 대화를 다시 시작 할 수도 있다.

카드에서 더 큰 숫자가 의미하는 것은, 공수산정에 더 많은 불확실성을 포함하고 있다는 뜻이다. 따라서, 만약 한 개발자가 6을 내고 싶은데 다시 고려하고 싶은 경우, 불확실 성이 존재하지 않아 보인다면 5 자리를 내거나, 아니면 보수적으로 불확실성을 고려해서 8자리 내면 된다.

장점 

Moløkken-Østvold 와 Haugen의 연구에 의하면,  
동일 프로젝트에서 개별 전문가에 의해 조율된 업무 공수 산정 수치들은
플래닝 포커 작업을 통해서도 유사한 정확도를 달성했다,
반면에, 플래닝 포커와 조정 그룹, 두 그룹 모두 중간 산정 편향 수치에서
편향되지 않은 결과를 보였으며, 이는 마치 전형적으로 산정된 업무들처럼 정확했다.

참고자료 

 

애자일 소프트웨어 개발
소프트웨어 프로젝트 관리
소프트웨어 개발 철학