Thursday, December 22, 2011

Why Planning Poker

Why Planning Poker

Planning Poker is one of the (for some people this only !!!) agile estimating technique that is derived from Wideband Delphi which is widely used in waterfall model with an exception of advocacy. This technique has become more popular after Mike Cohn added in his book “Agile Estimating and Planning.”

How to play Planning Poker?
We can use following very basic steps to arrive good estimates


  1. Each participant is given a deck of planning poker cards representing a sequence of numbers in Fibonacci sequence (?, 0, ½, 1, 2, 3, 5, 8, 13, 20 (why not 21?), 40, 100). I recommend to use Fibonacci when compared to sequence of numbers like 0, 1/2, 1, 2,4,6,8 etc as Fibonacci sequence will not allow you to multiply or divide number among the estimators. This can lead to anchoring.

  2. The scrum master presents one user story at a time

  3. The Product Owner (or equivalent role) explains the user story to the team and answers any questions the team might have about the story.

  4. Each participant selects a card representing his or her estimate of the user story privately. Team advised to take effort, time, risk, complexity, dependency with other stories or systems and any other relevant factors in consideration.

  5. All the participants are expected show their estimates at once. I always utter “SHOW !!” to let participants show their estimates at once.

  6. Life is good if there is a consensus in first go. Appreciate the team and record the estimate.

  7. It is very likely that the estimates differ. Allow the high and low estimators to voice their opinions. Let the team debates briefly and show their estimates.

  8. Continue previous step until consensus has been reached to record the estimate.

  9. Repeat for all stories.

Is your life as easy as stated above?


Scrum team consists of developers, testers, database engineers etc. It is quite common to have different viewpoints and different solutions based on their skills and tastes. After all we are human beings having unique psychology. It is obvious to have difference of opinion among us. Otherwise we all could have called as ROBOTS than HUMAN.



  1. Developers thinks the complexity in terms of writing code. Tester thinks the complexity in terms of testing the application. E.g: Developers can use default exceptions in coding whereas , testers should test all possible scenarios using decision tables n this scenario testing job is complex and developer job is simple. Some times developers need to generate complex algorithm to solve the problem, that might result simple testing. So, their estimates differ.

  2. Sometimes the user story looks simple for an experienced team member while it looks complex for a junior team member. Experienced member will start anchoring.
    We ask everyone in the team estimate irrespective of their role in the development of specific user story. This will lead to misunderstanding of user story and differ the estimates largely. E.g.: if a team consists of 2 java developers and 5 integration experts (like Pega or Sales Force etc). Java developers tend to write tons of lines of code and feels the user story is complex, where as Pega or Sales Force type developers look at reusable components to complete. For them this is simple.

  3. No consensus even after 3 – 4 rounds of discussion.

I use to apply following techniques to get the quick consensus among the human beings ( :-) )



  1. Make sure that those who actually work are the ones to vote. It is quite common in agile teams that everyone vote even if they have no idea about the work involved in the story. This reduces the aberration in estimates. If it is Java related development, let all Java team member vote not others.

  2. Let the experienced team members sin in listening mode most of the time. This allows others to think on their own. Experienced team member can pitch in if the discussion is going in wrong direction. He/she can jump into the discussion for conclusion and show his/her estimate after every one shows their estimates.

  3. If there is a conflict between QA and Development teams, conclude the discussion by taking highest number as benefit of doubt. But, this should not become practice.
    Scrum master can ask the teams to compare with other stories already estimated. If one of the team member says the size is 5 and other member says 13, ask them to compare with previous stories estimated with the same size. Ask following questions to the team “how bid when compared to that?” or “Why it is as small as this?” etc. This enables the team members to think relative estimates.

  4. Use timers to make sure that we not spending more than stipulated time. Move on to next user story if we are not getting consensus even after 3 – 5 rounds. Visit this story towards end of planning session

  5. Arrange meeting with the person creating the user stories. QA and Development teams prior to playing planning poker. This helps the tam to save time during estimation.
    Do not allow implementation discussions in deep. Even though we get granular estimates after longer discussion, we may end up spending more time than expected and may leave some user stories without estimates.

  6. Allow the team to go for task breakup offline if some user stories of high priority could not yield any consensus. Such stories can be taken up after break or after checking e-mails, updates in facebook, and twitter etc. This allows team members to work independently with fresh mind. Reconvene to complete estimates.

How to deal with distributed teams?



  1. Now a days, it is quite common scenario to have distributed team working as a single scrum teams. For example, we often find it difficult to manage if Product Owner in New Jersey and developers in Bangalore. We still can get effective estimates with some adjustments in our process

  2. We can use any one of the following online collaboration tools
    http://www.planningpoker.com/ developerd by Mountain Goat Software.
    http://www.expertware.no/estimationweb/ developed by PGS Software
    http://kevinverhoef.nl/poker/ developed by Kevin Verhoef
    Spead the planning meeting for 2 – 4 days with 1 hour a day. This helps offshore and onsite teams to meet at convinient time. Also teams can do some home work incrementally to get ready for estimation.

  3. Perform pre-planning estimation at offshore or insite seperately. Have detailed discusion on user stories larked for planning. Go for poke planning estimation together. This saves lot of time.

    Go for planning poker estimate by giving these tips will help your team to provide near accurate estimates

Please feel free to provide your thoughts to improve this article