Photo by Michał Parzuchowski on Unsplash

What is Planning Poker?

Project planning requires estimates. In a typical waterfall project all the work tasks have time estimates (usually in days) and deadlines. By applying task dependencies and resource levelling a project end date and cost are determined.

Agile projects have the same need to determine a project end date, but the estimate system works very differently. A common Scrum practice is to use Planning Poker. Planning Poker leverages the knowledge of the team to estimate work effort. This aligns with the idea that the team is responsible for the work. Planning Poker uses a relative point system and does not attempt to measure effort in work time or duration, just a level of difficulty relative to other items in the backlog.

Agile Release planning leverages this poker point system to determine when product releases can occur and how many sprints are required to complete the project. For this article I am going to focus in on how points are assigned to project deliverables using a process call Planning Poker.

The Planning Poker Point System

The fibonnaci series forms the basis for the Planning Poker point system. The standard card set includes 0, 1/2, 1, 2, 3, 5, 8, 13, 20 (or 21), 40, 100 and a take a break card usually represented with a coffee cup.

Planning poker estimates (Poker Points) are for User Stories, not for tasks. Remember that User Stories are simple, business readable descriptions of the features that need to be delivered in an Agile Project. User Stories are collected into a list known as the Product Backlog. Stories represent project deliverables that have to meet a definition of done.

Poker points are used to measure Sprint Velocity, this is a measure of how many points can be completed in a sprint. If you have Poker points assigned to all items in a backlog and a Sprint velocity, you can determine how many sprints the team will take to complete the backlog work by dividing the velocity into the total points in the backlog.

For example if you add up the points on each story in your backlog and you get say 100. If your sprint velocity is 10; where you are completing 10 points worth of stories per sprint, you will need 10 sprints to complete all the work in the backlog.

The Planning Poker Process

So how does Planning Poker work? The Product Owner or Scrum Master usually host the Planning Poker sessions. These are meetings that include the whole team. I like to set up recurring 90 minute weekly meetings with the project team. The Product Owner or someone that can speak to the User Story requirements should attend.

If you can provide prereading for the team and an agenda of the stories that will be covered, that is highly valuable to a smooth and productive estimation session. Planning Poker discussions can get lengthy. It helps if team members come prepared with questions and an idea of what will be covered in the meeting.

Baselining

The Poker Point scale is relative. A 2 is approximately twice as complex as a 1. A 3 is about as complex as three 1’s or a 2 and a 1.

So any estimate is a comparison. If no stories have been estimated, your estimate cannot be compared to anything, so we need to baseline.

Choose a small story from the backlog to serve as the baseline. Something that can be done in a day or so, including the testing work. This baseline story can be choosen from anywhere in the backlog. Just pick something that looks small. Put a 1 on this story. This is your baseline, every estimate is a comparison to this story.

User Story Description

The Poker Planning cycle starts with the Product Owner presenting the story to the team. The story is read aloud and visually shared with the team.

User Story Discussion

Once the Product Owner reads the story and acceptance criteria, there is a period of discussion and question and answer. Unknowns can be addressed by making assumptions and stating them on the User Story.

This Q and A is a valuable way to engage the team with requirements and to refine the backlog. See my article on Backlog Grooming for more information. Be sure to time box the discussion as this will limit your estimation throughput. The Poker Estimate is meant to be a high level guess, not a rigorous measurement.

Initial Estimate

Once the team understands the requirement and what is involved, it is time to play some poker. This stage works as follows

• Remind the team of the baseline story
• Each team member secretly selects an estimate card (using an app, or a physical deck)
• Every team member is ready and keeping the card secret
• The ‘Caller’, this can be the Product Owner or Scrum Master, or any volunteer, says “Show Estimates”
• Team Members display their estimates to the rest of the team.

Estimate Discussion

When estimates are revealed, if the estimates are the same for all team members, that is the number to add to the User Story. This is rarely the case, especially on a new project.

Team estimates are likely to vary. This is where team members with widely varying estimates can share their thinking. Perhaps the developer with the low estimate has an insight into a library that makes the work easy, perhaps a tester has insight into complex scenarios.

Concensus Estimate

The purpose of Planning Poker is to achieve a team estimate on each backlog item. Once the team has discussed the estimate differences run through the poker exercise again. The new information should get you closer to concensus.

Strictly speaking this process continues until you reach full concensus, but I typically go with the clear majority. If there is still an estimate that is far different from the rest, this needs to be resolved with further discussion. A story that cannot reach concensus might just be a question mark requiring a research spike.

Summary

Does Planning Poker work? Absolutely. I have run many agile projects and used a poker point system to project the duration. This technique has proven to be very accurate. Its success however does assume a few things,

• The Project Team stays constant, adding or removing team members will create an unstable velocity
• The point system isn’t being gamed to artificially show improved velocity
• The project has enough sprints to achieve a stable velocity, 10 or more

Source Cited

The following articles provide further insight into the Agile Planning Poker approach

• Mountgoat Software
• Product Plan

Icons made by Freepik from www.flaticon.com