What is Planning Poker? – Agile Estimation Techniques

What is Planning Poker?

Planning Poker is a highly efficient agile planning and estimating technique which has become exceptionally well-known over recent years. It is based on a procedure known as Wideband Delphi that was made by the RAND Corporation between 1940 and 1968, the exact year unknown. The method was polished by James Grenning in 2002, and it gained a greater popularity when it was incorporated into Mike Cohn’s book, ‘Agile Estimating and Planning’. The primary strategies have been around for a long time, but the refinements done by Grenning have been welcomed by agile teams who have taken full advantage of it.

Game Flow

1. Each member gets a set of cards representing a sequence of numbers. Common and prominent sequences include doubling numbers, (0, ½, 1, 2, 4, 8, 16, and so on.), the Fibonacci series (1, 2, 3, 5, 8, 13, 21,  T shirt sizes, (S, M, L, XL, XXL) etc. The Fibonacci sequence is more common and easier to go with.
2. The Scrum Master presents a single story at a time.
3. The Product Owner answers any queries the team may have with regard to their user story.
4. Every member secretly chooses a card that represents their estimate of the ‘size’ for their story. Generally, the story size (also known as story points) is estimated based on the time span, risks, complexity and other significant elements related to the User Story.
5. When everyone is ready with their card, all cards are revealed.
6. When there is an agreement on a specific number, the Scrum Master records the size of the story and the team moves on to the next story.
7. More than likely, there will be a disagreement on the number, so the members who have highest and lowest estimates will be asked to justify their numbers.
8. There will likely be a debate between the members to come up with a new set of estimates, which will, in affect, demand a replay of step 4) and step 5)
9. Continue this until an agreement has been arrived at.
10. Repeat this for the rest of the stories.

People who advanced through using Planning Poker can see a number of fundamental reasons for its success. Individuals like Mike Cohn were highly instrumental in bringing this kind of poker into the limelight. He also made planningpoker.com so individuals can have the capacity to play the game with dispersed groups.

Rules of the Planning Poker Game

1. People with responsibility certain tasks will vote on them
   Quite often, agile teams let everybody vote, even when they have no knowledge about what they are involved in.
2. Managers should not vote
   The responsibilities of a manager or chief are not usually time intensive, so this tends to skew their votes too low. Therefore, they are advised not to vote but it is wise to let them have the veto over the group agreement in one instance. When the case size has increased abnormally the manager can inquire as to whether the team have contemplated something that’s not in scope which may have increased the size. He or she can make these types of suggestion but they have no authority to direct the team to decrease the size.
3. Picking the larger size or points during ties
   At the point when there are ties while voting between two consecutive sizes or points, simply choose the bigger size and proceed forward. Keep in mind that back to back sizes may be 5 and 8, if you are going with the Fibonacci series for estimating. Nobody will complain about choosing the higher number, because it is acknowledged that a tie takes time to solve.
4. Don’t embark on a deep implementation discussion
   Groups generally drive down to specialized points of interest when they talk about a user story. It is fine to a certain extent, but it needs to be restricted because of time restraints. Close to a one minute of discussion will suffice. The more time the team spend thinking, the more complex will estimation become. So a team is advised to take the much simpler route to the solution which will allow them to estimate the size much quicker.
5. Use the ‘I need a break’ card
   While the team is playing hard we shouldn’t forget that some members might need a short break. They can use the ‘I need a break’ card which lets them attract everyone’s attention for the needed break.
6. Use timers to reduce discussion
   As discussed above, discussions will have to be limited to a minute, so timers may be used for this.
7. Picking the largest size on the third round
   If you don’t reach a consensus by the end of your third round after voting, you need to take the highest size and go ahead. By picking the biggest size, the team is given enough time to do the work. It also limits the danger of members complaining that they don’t have enough time to do the tasks when the actual work starts. So the safer the better.
8. Let the Product Owner meet QA leads and Development leads ahead of time
   To make sure all the questions regarding the user story are answered, the PO meets the Dev and QA leads prior to the Planning Poker meeting. This enables the team to concentrate on size, instead of investing energy in gathering information during the game session.
9. Don’t forget the baseline
   Whatever the team chooses as a pattern should be consistent across all iterations. In the event that a day is selected as size then it has to be used as a reference point for rest of the iterations as well. If a particular user story is size 1 or size 3, it has to remain constant through the iterations.

Summary

The main reasons why planning poker has succeeded is because:

• It needs the entire team to collaborate
• It establishes a consensus estimate rather than keeping one person driving it entirely
• It exposes issues before time and within the course of the user story, not at the end

But the key thing to success is the fun side of the game which agile scrum teams tend to enjoy. Happy poker playing!