Planning poker is a widely used technique for estimating in agile teams. In this article, I will share some of my experiences and tips for running a successful planning poker session whether it is on-site or online in a virtual workshop.

Why use planning poker?

Planning poker is a fast and fun way to estimate the effort or complexity of work. It is a great technique for teams that want to improve their estimations that can lead to some interesting, perhaps even unexpected, results.

Here are some reasons why planning poker is beneficial:

• Encourages team collaboration and discussion. Planning poker brings the team together to discuss and share their perspectives, leading to better estimations and improved teamwork.
• Helps identify discrepancies in understanding. Planning poker helps identify any discrepancies in understanding and allows the team to reach a shared understanding.
• Unbiased estimations. Planning poker allows team members to independently form their estimations without being influenced by others.
• Fosters team engagement and buy-in. By involving the entire team in the estimation process, planning poker increases engagement and buy-in, leading to a more committed team.
• Increases cross-functional knowledge. Planning poker encourages cross-functional knowledge sharing, which can lead to a more T-shaped team.

To run a successful planning poker session, there are a couple of things you need to consider and think about:

• What estimation scale to use, for example Fibonacci or T-shirt sizes.
• If you will do the planning on-site or in a virtual workshop online.
• How to get everyone involved and avoid biased estimations.

This is the focus of the rest of this article, but let’s first take a look at how planning poker works.

How does it work?

In planning poker, the team gathers to estimate the effort required for backlog items. Here’s how it typically works:

1. The facilitator presents a work item to the team, for example a user story.
2. Each team member privately selects a value from a predefined scale based on their understanding of the effort required relative to other items in the backlog.
3. Everyone reveals their estimation simultaneously.
4. If there is a wide range of estimations (more than two steps between lowest and highest estimate), the team discusses the reasons behind their choices. A good practice is to ask the ones with the lowest and highest value, respectively, to speak first. This makes it less likely that the same persons speak up every time.
5. Repeat the estimation process until a consensus is reached. This doesn’t necessarily mean that everyone has to agree on the same value. If people are within two steps of each other and ok with the value picked, you can consider that a consensus.

Click to expand

Let’s consider an example to illustrate how planning poker works.

The team has decided to use the Fibonacci sequence as their estimation scale (more on scales later), and selected a backlog item to estimate.

1. The facilitator presents the user story to the team: “As a user, I want to be able to log in to the application.”

2. Each team member privately selects an estimate. For example, the team members might select 1, 2, 3, and 8.

3. Everyone reveals their estimations at the same time to avoid anchoring bias.

4. Because there is a wide range of estimations the team discusses the reasons behind their choices. The facilitator asks the persons with the lowest (1) and highest (8) value, respectively, to go first.

   Click to expand

   

5. Another round of estimation is conducted, and the team members privately select a value again. This time, the team members select 3, 5, 8, and 8.

   Click to expand

   

6. After revealing their estimations, the team agrees on an estimation of 5 for this item. While not everyone picked the same value, the team considers this a consensus because everyone is within two steps of each other, and everyone is ok with the selected value (5).

What scale should we use?

A lot of different estimation scales can be used for planning poker. It is very much a matter of preference, and depends on the requirements of the team and the organization. Below I have listed some common scales and their advantages and disadvantages according to my experience.

My preferred scale is a modified Fibonacci sequence, as it provides a good balance between precision and simplicity. The finer grained small estimates work well for small items, while larger values are adjusted to be more coarse grained. You can also add a 0 and/or ½ point to the scale to represent items that are so small that they require minimal or no effort.

Regardless of the scale you choose, it’s important to remember that the scale should reflect the relative effort or complexity of the work. It should not represent calendar time or other absolute values.

If there is a high risk of thinking in calendar time, T-shirt sizes might be a good alternative. (If necessary you can translate the sizes to numbers behind the scenes.)

How do you reach consensus in a cross-functional team?

One thing teams new to planning poker sometimes struggle with is how to reach consensus in a cross-functional team with developers, designers, testers, and other roles. “How can I as a developer estimate the design work?” or “How can I as a tester estimate the development work?” are common questions.

This is not as difficult as it may seem. The key is to focus on the relative effort or complexity of the work, and not the absolute time it will take to complete it.

Over time the team will learn to understand each other’s perspectives and even gain a better knowledge about all aspects going into the work - not only their own aspect. Not only will this lead to better estimations, but it will also improve team collaboration, and reduce the risk of silos and waterfall behavior inside the team.

A product owner friend of mine once told me that after a while she could pretty accurately predict the team’s estimations. The experience from previous backlog items and listening in on the discussions during planning poker had given her a good understanding of the team’s perspectives and considerations.

Do you need a dedicated deck of cards?

While planning poker decks of cards exist, I prefer keeping it simpler still.

On-site

In an on-site setting, I usually just ask people to hold up their hands with the number of fingers corresponding to their estimation. For numbers larger than ten a fist is used to represent ten, and the other hand is used to represent the remaining number. For example, 13 is represented by a fist and three fingers. Two fists could represent 20. Larger estimates than that are rare, and can be handled separately when they occur.

Virtual workshop online

In a virtual workshop with a distributed team, I prefer using a simple online tool like our own Planning Poker tool. Some teams simply put numbers in the meeting chat, but I find that this can be confusing and it also means spamming the chat with numbers. (Especially annoying if you are not in the meeting at the time, but get notifications for the chat.)

In a mixed online and on-site setting, I usually ask everyone to use the online tool, even if they are on-site.

Common Pitfalls and How to Avoid Them

While planning poker can be an effective technique, there are some pitfalls to be aware of:

1. Anchoring bias. Be cautious of too detailed discussions upfront, as it can influence the team’s estimations. It might also mean you spend time unnecessarily on discussions that are not relevant to the estimation. Keep the initial discussion short and focus on the business purpose of the item before the first estimation round. Avoid giving estimates away beforehand, or even hinting at them.
2. Reluctance to estimate. People can be reluctant to estimate items outside their area of expertise. Encourage knowledge sharing and an open mindset to ensure that everyone feels comfortable estimating all or most items. You can also add a way to indicate that you have absolutely no idea. (Online tools and dedicated planning poker cards often include a card specifically for this.)
3. Basing estimates on calendar time. Make sure that the team understands that the estimation scale is relative and not calendar time. Sometimes teams find their “relative reference” by estimating a few items in calendar time or saying that for example “one” represents one day. I strongly discourage this practice as it often proves difficult to let go of this initial hack.
4. Separate estimates per discipline. If you have a cross-functional team, it is important to estimate the work as a team, and come up with one estimate per item. If you estimate separately per discipline, you will not get the benefits of cross-functional collaboration and knowledge sharing.

By being aware of these common pitfalls and implementing strategies to mitigate them, you can maximize the effectiveness of planning poker and improve the accuracy of your estimations.

Conclusion

Planning poker is a valuable technique that can be used both on-site and in online virtual workshops.

The biggest benefit of planning poker is probably not be the estimates themselves, but rather the discussions and knowledge sharing that happens during the estimation process. This can lead to more team engagement and buy-in, empathy for others professions, and even increase the team’s overall domain knowledge and T-shapedness.

If you want to try planning poker, I would love if you give our online planning poker tool a go. If you have feedback or suggestions on how to improve it, I’m all ears!