Planning Poker

Planning Poker is an Agile planning and estimating technique. It is a consensus-based technique used to estimate the product backlogs by the Agile teams worldwide. Planning poker is done with story points, ideal days, or any other estimating units. To estimate the Product Backlog, a customer or Product Owner reads the user stories or describes the features of the product to the estimators.

Planning Poker is a technique for sizing PBIs.

Planning Poker technique was first described by James Grenning (Grenning in 2002) and then popularised by Mike Cohn (in 2006). Planning Poker is based on the following few important aspects.
Planning Poker technique estimates the efforts. In the activity, the experts engage in the discussions on Product Backlog Items (PBIs) to reveal the assumptions, gaining a shared understanding, and sizing the PBI. Planning Poker produces relative size estimates by grouping the similar-sized items.

What is an Estimation Scale?

Estimation Scale provides a sequence of numbers to assign estimates for implementing Planning Poker activity. Generally, a team doesn’t use all the numbers from the scale as the goal is not precise. Rather, a team support a scale of sizes with more numbers at the little end of the range and more broadly separated numbers at the extensive end of the range.

Mike Cohn has proposed one scale based on a Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, and 100. This is the most frequently used scale in the Agile organizations. Some teams use the scale which is based on powers of 2: 1, 2, 4, 8, 16, 32, . . . 

The teams group the like-sized PBIs together and the same number is assigned to them while using this type of scale. To illustrate the concept, consider one example of a postperson at post-office. The postperson groups the same area letters in the area-wise boxes (from a close area to far) to ease the process of letter delivery.

Similarly, the team members (estimators) discuss the PBIs asking questions to the Product Owner. When all the features are discussed completely, an estimator picks up one card to depict team members’ estimate. At the same time, all cards are then revealed to others. If all the estimators choose the same story points, that will be the final estimate to that story. If not, the team members discuss their estimates to come to a conclusion.

The high and low story points estimators need to share their reasons. After a discussion, each team member again selects an estimate card and all the cards are again made open for all at the same time. This process continues until the team reaches the consensus or the estimators come to a point that Agile estimating and planning of a particular item needs to be postponed until an additional information is obtained.

When should we hold a Planning Poker activity?

Most of the teams hold a Planning Poker activity soon after an initial Product Backlog is composed. This session is used to create the initial estimates that will be useful in sizing the project.

Teams find Planning Poker activity very helpful for conducting Agile estimating and planning sessions once per iteration.

Why is Planning Poker used?

Planning Poker activity is used to evade the impact of the other participants. If one number is spoken, it can be viewed as a recommendation and impact other team members’ estimating. Also, Planning Poker compels individuals to think freely and propose their numbers simultaneously. This activity is accomplished when all the team members reveal their card at the same time.

Who all participates in Planning Poker?

The Scrum Master, Product Owner, and the development team participate in Planning Poker activity.  The Development Team sizes the user stories.

How to play Planning Poker?

During the activity-

• The Product Owner explains, presents, and clarifies the Product Backlog items.
• The Scrum Master coaches and helps the team in carrying out the activity in a better way. Also, the SM continually searches for individuals who, by their body language or by their quietness, appear to disagree and helps them engage better.
• The development team generates the estimates collaboratively. Each development team member is given a set of the Planning Poker cards as shown in the figure below.
  

A common interpretation of numbers on the Poker cards is described in the table below.

Planning Poker Rules

The rules for playing Planning Poker activity are as follows.

1. The PO selects a PBI which needs to be estimated and reads that to the team.
2. The development team members carry out a discussion on the selected item and ask pertinent questions to the PO.
3. The PO answers the queries.
4. Each team member secretly picks up one card to represent his/her estimate.
5. Once all the estimations are done, these are exposed to all the team members.
6. If everyone selects the same card, they do consensus, and that number becomes the PBI estimate.
7. If the estimates are not equal, the estimators have a discussion to come to a common justification. Or else, the high-low story points estimators are asked to explain their estimates.
8. After the discussion, they go back to step 4 and repeat till the consensus is reached.

Does this activity yield benefits in the Agile world?

• Planning Poker activity plays a major role in collaboration. The activity brings various team members together to arrive at a consensus on an accurate estimate than any individual could fabricate alone.
• This activity motivates people to think about the product backlog items (PBIs), coming out with some valuable ideas to reach consensus. Planning Poker facilitates the discussion on Product Backlog items (PBIs).
• Since the Planning Poker activity is based on the discussion, it provides a better understanding, resolves queries as the team members share their inputs on product backlog items. Also, the team members got size estimates on the Product Backlog Items (PBIs) and they must have reaped a good return on the team’s investment.

Planning Poker is an engaging act and a productive approach for estimating the user stories. As, the activity is all about a discussion, not only is it painless for the team members to arrive at a consensus but also provides a wide view for implementing a user story at hand.