Planning Poker, also known as Scrum Poker, is one of the most popular estimation technique used in Agile. It’s used to estimate the relative effort (in most cases) of the Product Backlog Items. There are two main reasons for which this method has been created: (1) to optimise time needed to provide an estimation while (2) allowing all team members take part in it.
Planning Pocker was introduced by James Grenning in 2002 in paper “Planning Poker or How to avoid analysis paralysis while release planning“. Later it was popularised by Mike Cohn in “Agile Estimating and Planning” in 2005. Both positions are worth to read if this post is not enough for you (the first position is very short and very valuable).
What you need to play?
It is very little you need to play Planning Pocker. All you need are: the set of User Stories which need to estimated, the Product Owner who will be presenting (you can think of him/her as a dealer), facilitator (it can be either Product Owner or Scrum Master) who is not playing, the Development Team who in fact do the work and last but not least deck of card.
For this Pocker game, a specific deck of cards need to be used. Each player (member of the Development Team) holds cards with the number representing estimation. The most common deck is Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21, etc.).
How it works?
(1) The Product Owner presents the User Story, and the Development Team has the opportunity to ask the questions in order reach the common understanding. It’s also a time for a brief discussion what needs to be done and how it needs to be done to satisfy presented Acceptance Criteria. The summary should be documented. (2) Once the discussion is done each member of the Development Team select one card which represents his/her estimation and put it face down. (3) After all, cards are down everyone reviles their cards simultaneously. (4) If all cards have the same estimation, then we can move to the next User Story <1>. The work has been done. (5) In case there are some different opinions person with highest and lowest estimate should justify their selection. After that, the team can engage in an additional discussion to comment presented arguments. But the game needs to be repeated <2>, and the Development Team need to take back cards and select once again. This process needs to be repeated until some consensus is agreed.
In case you are not able to get consensus, and you cannot play to infinity, you can:
- get the highest estimation
- get the lowest estimation
- get the estimation selected by the majority of the team
- put this user story on hold until more information are available
Pros and cons of the Planning Pocker
It’s great that for that estimation technique the whole Development Team is invited. More people are involved more likely that some hidden impediments will be located. Moreover, during the estimation, the team can agree on the approach which will be taken to build given functionality (resolve some issue). In spite of the number of people involved in this process, the game is constructed to be time-efficient.
At some point, we can find ourselves in situations that compromise is not likely to happen. The facilitator needs to be prepared for such situation. He or she needs to be ready to help the team resolve it with some other methods.
Distributed teams
This method has been designed for collocated teams. But nowadays, we have plenty of tools allowing us to play even if you are running distributed teams: Planning Pocker for JIRA and Hatjitsu are the one I use with my teams. You can also show your hands (with a propriate number of fingers) into a camera during Skype call (been there too).