What is Planning Poker in Agile?

In Agile Methodology, one term that you will regularly come across is “Planning Poker”, but what is it exactly? Well, sadly, it’s not organizing a game of stud poker with your workmates in your lunch break because the business you work for has just adopted Agile. As attractive as that may sound to some, Planning Poker is something different although with some similarities, hence the origin of its name and our freedom to indulge in a few analogies here. It still contains the three core elements of the famous card game, namely strategy, skill, and to a certain degree gambling, but where it differs most is that this is a team game, not an individual one.

The Creation of Planning Poker

In one sentence perhaps Planning Poker could best be described as an estimation and planning technique which is based on team consensus and used primarily after a product backlog is written. The creation of the tool in 2002 is accredited to James Grenning who felt that the prevalent estimation approach at that time, known as Wideband Delphi, was both too time-consuming and had serious limitations in its involvement of the most suitable members of the entire team. Wideband Delphi had its roots in the 1950s and was still being used at the turn of the century along with other rather antiquated techniques.  

The Poker Game and the Players

Planning Poker depends upon input from all the experts with their different fields of expertise who are actively involved in a project’s story. From the product owner to customers, programmers, testers, database engineers and designers, all those relevant within the cross-functional team to what is going on and to what is envisaged. Estimation in any project, not least software development, is a major challenge needing careful thought and implementation and, as teams and projects increase in size, inadequate planning and incorrect estimations will usually prove disastrous. By involving more specialized and competent people in estimating the work effort required to implement the same project, estimates will undoubtedly be far more accurate. Similarly, if the whole team takes part, greater collaboration naturally ensues, whilst, at the same time, any problematic issues will be discovered earlier in the project.

The Rounds in the Game

1. The product owner or customer reads an agile user story or describes a feature to those assigned the task of estimating.
2. Those same estimators, namely the team members of the group, fully discuss the feature and, where needed, ask the product owner any relevant questions for greater clarification.
3. Once this discussion is finished, each estimator selects one card with a numerical value equivalent to his or her estimate of the level of complexity of the story. The card is then placed face down on the table. The number on the card shows each person’s individual estimation of the story points needed to complete, based on the natural Fibonacci Scale; 1, 2, 3, 5, 8, 13, 21…, although slight variations to that scale or other units of measurement may be used.
4. The cards are then turned over and shown simultaneously by the estimators. If this was poker the card game, it would be the moment when we’re all on the edge of our seats watching the end of a Las Vegas casino film; an emotionless, granite-faced player finally turns over his cards to reveal his winning or losing hand. In Planning Poker it’s not quite so dramatic and doesn’t end there.
5. Should the estimators all select the same number that obviously becomes the final estimate. However this is rare, so in most cases where all the estimators’ numbers are relatively similar, those who have chosen the highest and lowest values explain the rationale behind their choice of number to the group and a consensus is reached. Having to justify their logical basis for estimation at this stage compensates for information which may have been missing from the rationale of others in the team.  
6. If the reasoning and explanations have finished and no consensus can been reached, the estimators repeat the process from round 3 and continue until an agreed number is found. It is unlikely that any equal split will be resolved that quickly so in these circumstances rounding up rather than rounding down takes place. For example, if there was an equal split in story points between 5 and 8 on the Fibonacci scale, a team would choose 8.
7. Repetition of the process is not recommended beyond 2 or a maximum of 3 rounds of voting but if a consensus can still not be reached, the estimating and planning of an item may be postponed until additional information becomes available.

Playing Time           

As mentioned, the Planning Poker session is held shortly after the compilation of the product backlog and may be spread over several days. User stories will then be identified and added throughout an iteration and hence most teams will conduct subsequent sessions at least once per iteration after a Daily Scrum. These sessions are best conducted several days prior to the end of an iteration as the whole team will still be together.

Time is also relevant when considering how long is spent in the session itself. In order to keep discussions productive, using a two or three-minute timer in the rounds definitely helps.

Playing for the First Time

If a team has no experience in the use of Planning Poker then the team members cannot draw on comparisons with past sessions in their estimating. The solution for first-time players is to establish a baseline and this can be done by getting them to discuss and identify two initial values for two different items. The values 2 and 5, or 3 and 8, are best for this since they represent items of lesser complexity and once identified, create a situation in which other items are more easily comparable. As an example in the latter case, if an item is considered harder than a 3 but easier than an 8 it would be estimated as a 5. This is clearly less accurate and more of a gamble than relative estimating for an experienced team but everyone has to start somewhere.    

Holding a Royal Flush

The best hand you can hold in the card game poker is a Royal Flush; ace, king, queen, jack, ten, all of the same suit. If you ever get dealt that, you’re a very lucky person. In Planning Poker being born lucky shouldn’t be such a prerequisite but it is important to remember that estimation is to some extent still a well-educated guess. However, in order to get the best results there are certain things that can help you:

-Experience

Besides the situation where you need to establish a baseline, calling on knowledge and past experience is done by everyone in all walks of life when it comes to considering how long something is going to take and how complex it is likely to be. The same goes for Planning Poker, so your best weapon is the use of comparisons with historical data from previously finished work items. Starting with a blank sheet in each session is particularly wasteful since you already have relatives to set your estimations against. So, no new baseline is required if the team members developing a new system are mainly those who were part of previous ones and the new item has similarities to the old.

-Avoiding an anchor

Often, a manager who is voting will vote with a low number since one of his priorities is how quickly the work will be done. In a position of hierarchical power, this could eventually persuade the rest of the team to reduce their final estimate. This is known as “anchoring”, namely that his opinion pulls down the estimate because of its weight. Anchoring is also used in reference to cognitive bias and should be avoided at all costs. In other words, like sheep, we humans tend to follow a leader so if we know in advance that he or she is estimating a story as low as 3, we are likely to do the same.

-Adopting Online Poker

Just as with playing the gambling version of poker, you can now do Planning Poker online. For teams that are geographically distributed and thus have difficulty in getting together face to face, this is a significant solution. The whole process remains virtually the same and, in the way that those involved are not actually in the same room, may well lead to more objective and rational estimating results. Finding your preferred version of this online application is easy since there is such a wide range to choose between.       

-Playing the Joker

Wouldn’t it be great if you could play a joker in poker? Unfortunately, you can’t, but in Planning Poker there is at least the “Break” card which can be played. This is simply a card which a team member can show in round 4 drawing attention to the fact that he, she or everyone could do with a break. Maybe more time is needed to consider the story, maybe not enough information has been given to the estimators, maybe the planning session has gone on too long and minds aren’t thinking too clearly or for whatever the reason, playing this card gives everyone a reinvigorating time-out.

It is also worth mentioning that there are two other cards available in the Planning Poker pack but not recommended if you want decisiveness; The “Infinity” card and the “?” card. The former represents the fact that the estimator thinks that the task is too big, the latter that he has no idea how long it will take. Playing either of these two, and particularly the second, is akin to folding your hand in a poker card game.

To sum up, we can say that if the card game poker requires strategy, skill and gambling, Planning Poker needs the same and more. And one other thing is certain; if you play it right, it stands to make you far more money in the long term than any lucky combination of diamonds, hearts, spades or clubs that you’ll ever hold in your hand.