Planning Poker

What is Planning Poker?

• Planning Poker is an Agile Estimation technique
• As we need to estimate our stories each Sprint Planning Meeting so it can be said an iterative estimating technique

In planning Poker team members will have a set of cards with different integer numbers. Fibonacci sequence of numbering i.e. 0, 1, 2, 3, 5, 8, 13, 21, 40 and 100 is recommended. Each member will select a card and assign is preferred point to a story. If point doesn’t match between members for any story then highest point giver and lowest point giver will explain why they chose that point for that story. After their explanation again start the game for that story. And this process will continue until estimates converge. If after 5–6 rounds of play the estimation doesn’t meet then put it aside for revisit later. However if estimate meets for the story then don’t need to play further for any story.

This is all about the story point. But we will explain it more details-

Brief Explanation

Step-01: Organization of the game

• Full team will involve in Planning Poker game.
• Will require 2–4 hours
• Also require a large table where all members will sit.
• Each team member will have a set of cards
• In each card set there will have 10 cards with numbering 0, 1, 2, 3, 5, 8, 13, 21, 40 and 100 i.e. 1st card’s no will 0, 2nd card’s no will 1, 3rd card’s no will 2, 4th card’s no will 3, 5th will 4, 6th will 8, 7th will 13, 8th will 21, 9th will 40 and 10th will 100

Step-02: Introducing Story by Product Owner

• The Product Owner introduces the user story by talking about:
• The motivation for doing the user story.
• The intended outcome and benefits.
• The scope of the user story (including what is not in scope with this user story).
• Other relevant considerations.

Step-03: Discussing about the Story

After introduction of the story team will ask their queries regarding that story until they have a crystal clear idea about that story. Some sample questions are-

• What should happen in a given scenario?
• What should happen in some negative case or edge case (i.e. plausible but not common scenario)?
• Do we need to build this for one type, several user types or all users?
• Do we need to track any new performance metrics in order to understand if this user story is working as expected?

Team can ask as many questions as they require to have a crystal clear idea about that story. Above those are some sample questions. Team will ask those questions to product owner.

Product owner will answer all those questions.

Note:

• If in case Product Owner fail to answer then Stakeholder will help Product Owner to answer those questions.
• If there are questions that the Product Owner as well as stakeholder cannot answer, he/she will find the answer before the estimation can take place.

Step-04: Playing Cards

• After discussion team members will ask to point for that story i.e. Product owner will ask them Now Select your card for assign Story Point to this story
• Each team member will select their card and put it on the table with face down, so that others can’t see his/her point.

Note:

If other members see the number during selection there have possibility of bias the estimation. One can estimate by influencing other’s given number. So be careful about disclosure of story point during selection time. Always face down your card when you select the card.

• Once everyone selected their card the product owner will say Now Show
• As soon as the Product owner say this everyone will turn over their card so that everyone present their can see the estimated number

Note:

During estimating a number for a story always consider what you discussed with product owner about this story as well as amount of work requires to complete this story, uncertainty, risk and complexity of the story. Selecting story points based on all those things are strongly recommended.

Step-05: Achieving Consensus

• Most of the time one thing will identify which is a huge mismatch between given numbers.
• In that case members with highest and lowest numbers will ask why their chose estimates
• They will give some justification and discuss with the team regarding this issue. This will also help the team if they have any misunderstanding or vogue idea about the story and adjusting their estimation
• After justification the process i.e. Step-04 will continue again
• This process will continue until all members agrees to a common estimate
• Once all team members agrees to a common estimate then Product owner will record that point and go for next story and will continue from step-02 to step-05
• If after 5–6 rounds of playing the game estimation fail meet all members agreement then put it aside for revisit later

Putting a story aside allows for:

1. The Product Owner do more research and provide more clarity.
2. The developers to investigate the technical options or details (reducing the technical uncertainty).

Step-06: Wrapping Up the Workshop

The Product Owner will note all estimates and keep track of them. He or she will also have kept notes of any discussion points, questions, and assumptions that came up during the discussions. This is valuable information and may also be added to existing documentation.

Note

• When the estimates are far apart or the team cannot agree, it is best to revisit the story once the product uncertainty or technical uncertainty are lessened.
• During play planning poker for the first time, some team members may be a little shy and try to wait to see other estimates before putting down their card. So to prevent such scenarios there is a strict rule that all cards must be down before you turn them over!

Mike Cohn has created this nice video that illustrates how consensus might be achieved during a poker planning session! The link is given below-

Benefits of Planning Poker

• Leverage the knowledge and input of all team members into the estimation process.
• Achieve a team-based consensus on estimates.