• 10 hours
  • Medium

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 7/26/22

Run a Planning Poker Workshop

Log in or subscribe for free to enjoy all this course has to offer!

What is Planning Poker

Planning poker is an iterative way of estimating with a team.

Team members have a set of cards that represent different estimates. Each member turns over their card to reveal their estimate.

The intended outcomes of planning poker are to:

  1. Leverage the knowledge and input of all team members into the estimation process.

  2. Achieve a team-based consensus on estimates.

Planning Poker Workshops

Planning poker involves the entire tech team. You will need 2-4 hours for the meeting and a large table where the team can sit with their sets of cards.

sd
The whole team sits at one table to play planning poker.

Use the following process each user story that you would like estimated:

  1. The Product Owner introduces a user story.

  2. The team engages in a discussion about the user story.

  3. Everybody puts a card down to represent their individual estimate.

  4. Cards are turned over at the same time and estimates are revealed.

  5. The team members with the highest and lowest estimates are asked to justify their answer. 

  6. Now the team plays again until the estimates converge. 

  7. After a couple of rounds, you can stop if the team members agree and are happy with an estimate. 

Let's examine some of those steps in more detail.

Introducing and Discussing the User Story

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.

At this point, the team can ask questions like:

  • 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?

Of course, the team can ask as many questions as they want! These are just ideas of the type of things the team will ask the Product Owner.

Playing Cards

Each team member will have a card for each of the available story point options. A set of cards like this are often called planning poker cards.

There should be a 1, 2, 3, 5, 8, 13, 21 and 100 card. (remember these are the numbers of the Fibonacci sequence)

After the Product Owner's introduction and follow-up discussions/questions are completed, each team member places a card on the table face down so their estimate cannot be seen. Once everyone is ready, the cards are turned over.

This method works best when team members give their unbiased and genuine estimates. Keeping the cards face down until everyone is ready prevents members from being influenced by others.sd

In real poker, you may glance at cards. But all players reveal cards at the same time!

Achieving Consensus

It is important that the team agrees to a common estimate.

The players with the highest and lowest numbers will be asked why they chose their estimates. They must then give some justification which the team will discuss. This may lead to everyone adjusting their estimate. It could also mean that the team keeps their estimate and the outlier folds.

Mike Cohn has created this nice video that illustrates how consensus might be achieved during a poker planning session!

The most important thing is that a consensus is reached as a team. If differences can't be resolved, consider putting the user story aside and revisiting it 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).

Once the team has achieved consensus on all items (except those put aside), then the planning poker workshop can end.

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.

Affinity Mapping

Affinity mapping is a variation of planning poker.

In this workshop, the team would:

  1. Choose a set of user stories that are representative of: 

    • A user story that is 1 story point in complexity.

    • A user story that is 2 story points in complexity.

    • Other user stories that represent all story  points (1, 2, 3, 5, 8, 13, 21).

  2. Take each user story to be estimated and compare them to your representative user stories asking, "Which of these user stories is as complex as this one we are currently estimating?" Then give the user story the same estimate. If this user story is most like the user story that is five story points in complexity, then it too has an estimate of five story points.

Summary

  • Planning poker is an iterative way of estimating user stories with a team.

  • A planning poker workshop involves all team members at one table, each with a set of planning poker cards (a card for each story point number).

  • This approach leverages the knowledge of all team members.

  • The end result is a team-based consensus on estimates.

Additional Resources

  • Agile Government Leadership have a nice guide to Agile estimation workshops.

Example of certificate of achievement
Example of certificate of achievement