What is Planning Poker?

Agile teams are creative, innovative, and above all have fun while they work—the perfect recipe for enabling project success! By doing away with rigid processes, dull documentation and inefficient practices, Agile teams are nimble and quick to react to changing project conditions.

One of the fun ways in which they work is by using Planning Poker to plan estimates and create schedules. In this blog, you will learn all about Planning Poker; what it is, how it works and what are its benefits and pitfalls.

Planning Poker, defined

‘Planning Poker® is the secure, fun way for agile teams to guide sprint planning and build accurate consensus estimates.’ - planningpoker.com 

This game-based estimation technique injects playfulness into what could otherwise prove to be a dreary, monotonous activity. Easily integrated into Jira and other Agile software tools, Planning Poker takes into account the opinion of every member on the Agile team and smoothens the process of creating accurate estimates, laying the foundation for planning and executing a sprint planning session.

What is Planning Poker in Agile all about? 

So, let’s get into what is Planning Poker in Agile and how it works! 

One of the most important meetings for an Agile team is the sprint planning meeting. The team members will sit together to deliberate on the amount of work that they believe is possible to complete during the upcoming sprint. This falls in line with the spirit of Agile, which allows for greater accountability and ownership of tasks. When the members themselves decide on the quantum of work that is possible, they are far more likely to get things done!

How does Planning Poker work? Let’s play Poker!

The Planning Poker game uses numbered cards to help estimate the effort or size of tasks in Agile development.  It pools in the estimates of individual team members to arrive at a shared consensus, which results in a fairly accurate estimate of the project duration. 

Here’s how to play: 

• Step 1: Distribute the cards 

Each member of the team is given a set of playing cards that are numbered in sequence. Mike Cohn, founder of Mountain Goat Software, put forward the sequence list that is widely in use today: 0, 1, 2, 5, 8, 13, 20, 40, and 100. 

• Step 2: The User Story 

The Product Owner reads out the Agile user story or may describe the feature to the estimators. He or she lays out the functionality that is required to be developed. 

• Step 3: Discussion and brainstorming 

The estimators hold a conversation with each other, discussing the user story and fleshing out the details. As they brainstorm, they might need to ask questions to elicit information. The Moderator, who could be the Product Owner, will record the proceeds of the discussion for further elaboration. 

• Step 4: Estimation 

Once the discussion is completed and all doubts are clarified, each estimator will select one Poker Card and place it, face down on the table. All members will then reveal their cards at the same time. In the event that all the values match, that is taken as the value of the estimate. 

• Step 5: Consensus 

In most cases, the values will not match as each team member will have their own reasons for selecting an estimate. Any outliers are discussed, and the estimators with the highest and lowest values must share their reasoning behind these choices. There is another round of estimation held after this discussion, where every estimator re-selects a card. This process goes on till the team members arrive at a consensus.

Where Did Planning Poker Originate?

This estimating technique has its origins in the year 1970 when Barry Boehm proposed ‘Wideband Delphi,’ an adaptation of the Delphi method which was already in use at the Rand Corporation as an estimating tool. It was called ‘Wideband’ as it built upon the earlier method to enforce greater interaction and open up more communication between the estimators. This was a forerunner of Planning Poker. 

Planning Poker was first defined in 2002, when software entrepreneur, James Grenning was looking for a simpler and more accurate way to cut out the confusion when creating estimates. Later on, in the year 2005, Mountain Goat Software’s Mike Cohn wrote a book ‘Agile Estimating and Planning’, where the technique was explicitly laid out in its current form, and the term was trademarked.

Expected Benefits

The rationale behind Planning Poker is that estimators are not influenced by the other participants, and apply their own thinking to creating their own estimates.  There are a number of benefits that arise from using this technique, the most important being the following: 

1. It facilitates greater collaboration and inspires teamwork between participants, and provides equal opportunities for every team member to have their opinion heard. This increases team morale and makes each person on the team feel valued. 
2. It encourages discussions, first during the introduction of the user story and later in case there are varying estimates. There are meaningful conversations that result from this process, and any ambiguity around the topics is dispelled. 
3. Estimates that are arrived at are fairly accurate, and it has been found that tasks that were not estimated using this method not only took longer to complete but also included more rework.  
4. As there is an increased understanding around the tasks, the code quality is much higher and implementation is smoother. 

Common Pitfalls

This technique is not without its share of pitfalls. Here are some of them:

1. Consensus is rendered obligatory, rather than a natural result of the discussions. This makes some people force their own decision making.
   
2. It could create a false sense of confidence, as people might think that they have arrived at the consensus, hence everything is clear. However, some points may still remain to be discussed.
   
3. It is possible that one person could have a dominant personality and take charge of the conversations. The rest may simply follow suit, without thinking things through properly.
   
4. If a team tries to size too many stories at the same time, it can lead to fatigue and inaccurate estimates.
   
5. Stories that lack sufficient acceptance criteria cannot be accurately estimated using this method.

Summary 

Agile is, by its very nature, fluid and dynamic and each team must figure out what works best for their project. While Planning Poker is a great method of estimation, some teams may find that they can create better estimates using other methods like Affinity mapping or T shirt sizing. If you are looking to create better collaboration between team members and nurture mutual understanding, Planning Poker is a good method to try. And as always, with practice and over time, you will find that your team’s estimation techniques will improve!