Estimation - Planning Poker®

Estimation in the agile world done right! How to play Planning Poker®?

by Pete R.

Planning Poker® is one of the tools used in Agile. The reason why it is useful is that it helps the team, decide how many of the points are allocated to a specific story or task. It helps mitigate endless discussions.

The described approach below gives you an indication of how the estimations can be achieved using Planning Poker®. Nevertheless, it is crucial to understand that every team is slightly different from each other and you might experiment and adapt the rules and the process to figure out the solution that works best for your team.

How Planning Poker® works?

When your team plays Planning Poker®, you rely on the expertise of the team members who are involved, and they provide their individual opinion on the user story at hand.

This technique helps the team to approximate the effort or complexity of a task and ensure that everyone is on the same page. The team can also resolve a different understanding of how to implement the story.

If anyone from the group chooses a different card, then there must most certainly be a debate and even arguments in some cases until the team has a consensus about their implementation.


To play Planning Poker®, you need the following prerequisites.

  • A scrum team that understands how Planning Poker® works
  • A group of developers that agreed on the stories described by the product owner in advance
  • A deck of Planning Poker® Cards
  • An agreement of the team if they estimate the relative effort or complexity
  • An understanding of what the agreed reference story is and how many points that are assigned to it
  • The Product Owner is reachable in case of inquiries or on debates splitting up stories

Let’s play

Deal the cards

Make sure every team member has a set of cards.

These cards usually have the following values and meanings:

A zero value indicates that nothing has to be done to finish the story. It's mostly used when a deployment is pending.
It's not zero, but it's a piece of cake that can be made with almost blind eyes.
It's a small story with very low complexity or effort.
Doubling up what a 1 means.
A little bit more than a 2.
This is an interesting card. There are some brainpower and effort involved to achieve this story. Widely used when the story starts to become serious.
Much more than a five, but still somehow manageable.
This number indicates that the user story is at a sharp edge to become too complex to be treated as just one story. Consider story splitting.
This card mostly just express some desperation of the team member. As a team, you should consider story splitting.
These cards mostly just express some desperation of the team member. As a team, you should consider story splitting.
These cards mostly just express some desperation of the team member. As a team, you should consider story splitting.
The question mark card shows up, that a developer has no clue how to estimate the story.
Sprint plannings can be exhausting. This card indicates that the team member requests a short break.

Agree on the reference story

Especially when you play Planning Poker® the first time. It is helpful to remember a story or task the team has finished recently and agree on a value.

This story will act as a “reference story” to estimate relatively to it.

Make sure, that you do not choose a too small or a too big story since this reference story should remain for more than just the next sprint to have a meaningful burndown chart and velocity over the whole project.

You can also skip defining a reference story and entirely rely on the gut feeling of your team. This works out better than it sounds at first sight.

Story by story

Now the team can open the first user story - ideally presented on a big screen or on a sticky visible to everyone.

Next, ensure that everyone understands “what” has to be done in this user story. This step is important and should be confirmed by every team member by a small sign (e.g., “thumbs up”).

Then ask the second question to the team if everyone has an idea in his/her mind of how to tackle the story. (Do not speak up loud or debate at this stage except when at least one developer has difficulties to come up with a solution or he/she has any uncertainties)


Now everyone in the development team (neither the Product Owner, nor the Scrum Master) picks a card silently and invisible to the other team members.

When everyone has prepared a card you turn it around simultaneously and show it to the team.

Now there can be the following outcomes:

…when everyone picked the same card

Perfect. Enter the agreed story points to the story and take the next story.

…when different card values are shown (no ? or “Coffee Break”)

This is the interesting part. It’s debate time. Never! Really never skip this part and just pick an average…

Set the stage for the debate: - Elect the most qualified person with the lowest number - Elect the most qualified person with the highest number - The team only elect 2 people in total, even then, when the highest or lowest number has been shown more than once

Now, the developer that represents the highest number starts explaining the thoughts behind the chosen card. - There is no discussion allowed at this stage.

After that, the developer representing the lowest value explains the thoughts behind his/her pick.

During this phase, the whole group gains insights about what others were thinking and can silently compare them with their own minds.

Without any further discussions, the next round of estimation takes place. Influenced by the prior explanations, everyone is allowed to change their mind and pick another card then in the round before.

Continue this iteration until everyone agrees on the same number.

…when a “?” card is shown up

Give this person a voice to post his/her concerns. And try to clarify it.

…when a “Coffe Break” card is shown up

Decide as a team whether or not and when you do a coffee break.

However the team decides, you should consider that one of your teammates is tired and would be happy taking a break to reshape his focus.

Special Situations

In this section, we would like to enlight some unusual scenarios that might happen and provide our recommendations.

One point difference

If there is just one point difference between the highest and the lowest card. You can also quickly agree on one of the value.

On the long run, this single point should not have any significant impact on velocity, nor productivity.

Distributions with a reasonable huge gap

Sometimes one part of the group has a solution that is more complex than the other part of the group.

This is a clear sign of having not the same understanding of “What” has to be done priorly described.

It’s recommended to involve the Product Owner and discuss the minimally viable solution this story can be achieved.

Remember, simplicity is king! Not in favor of technical debt. But try to avoid adding bells and whistles in the first iteration. You can always do this in another iteration when the priority allows it to do so.

Clarify and agree with the team on one of the implementation and re-estimate with the newly gained insights.

Someone refuses to adjust

Assume the team generally has consented, but just a few or even worse only one person refuses to find a compromise after several rounds.

In such a case it is helpful to remind everyone that this is an estimation. An estimation always includes uncertainties.

If this does not help, a more experienced developer having picked another number that is very confident that, they over or underestimates the story by far, can offer a pair-programming session to fulfill the story.

Also, remember the reference story, or a story you have just agreed on and bring this story into a relation to resolve the situation.

Leftover story from the previous sprint

Something it happens that the team could not have finished a story of the previous sprint, but has already started or is almost finished.

Such a story usually has some story points assigned to it. What to do now?

In this case, we need to remember that the velocity is an essential measurement in the long run. The story points can only be credited to the sprint where the story is considered as done. Therefore the previous sprint did not get any points for the effort invested until now. This means you should not adjust the estimations and lower the number for the sprint ahead of you. Take the story points in the new sprint to ensure a correct average on the long run.

Lack of experience in a particular topic

When there is a lack of experience for a particular topic by someone or a part in the team. You should estimate as if you would have the know-how.

“Lack of know-how does not increase the complexity of the story itself.”

Too many uncertainties with significant impacts

When there are too many uncertainties, consider planning a Spike that blocks this story and re-estimate the story afterward.

A Spike is an advanced Time-Boxed slot within the sprint where the team collects the know-how to achieve the story.

Do’s & Dont’s

Don’t work with margins

A less experienced or less stable team tend to create a margin on a task to compensate uncertainties in this or other stories by estimating a higher number than necessary.

Never do this! It’s ok, to take the wrong estimation from time to time. You also have to consider that you might achieve other stories with less complexity than you thought before.

The goal behind story points is to achieve a reliable and consistent velocity. Not to collect points.

Don’t compare with other teams

Estimations and story points cannot be compared with other teams. Every team agreed on its own reference story and might have a different range of cards they use.

Do Reflect after the sprint

To continuously improve your accuracy and reliability, consider reflecting your most under- or overestimated stories in the retrospective. And adapt in the next planning.

Accept flaws from teammates

Not everyone is an expert in all domains. Establish a respectful discussion culture while estimating and debating.

It’s the worst thing when someone does not have the heart to give any inputs anymore. You would most probably block an essential contribution in the future.

Let juniors joining the debates

Create some diversity when electing the persons that debates. Give junior developers a voice to figure out what they care about and how far they are in their personal development.

Giving them a helping hand by suggesting a pair programming session when you can help out to close a knowledge gap on a particular story. It’s a free lunch when it comes to improving the skills in the team continuously.

Stop when you have estimated enough points reachable in one sprint

Calculate your expected velocity before you start with the estimations. This way you can stop after a reasonable time or provide a signal to your Product Owner to provide you with more stories if it is significantly low.

To prepare a sprint backlog which is well-balanced, it is recommended to have the PO as a passive member in the room when you play Planning Poker®. This way, the Product Owner obtains a gut-feeling on which stories are involved and which aren’t.

Prepared sprint backlog refinements during the sprint for the next sprint is a handy technique to provide a more accurate number of backlog items. Backlog refinements can be achieved by only a part of the team or a single mature developer together with the Product Owner.

Don’t change estimations during the sprint

Regardless of figuring out that a story point estimation was wrong when you have worked on a story, never change the opinions during the sprint.

Instead, bring write it down and bring it up in the next retrospective so the team can learn and improve.

How to deal with compromises when implementing Scrum?

How to deal with compromises when implementing Scrum?

Using scrum can actually be the best decision which you could make for the organization as it has many advantages for everyone. It is a practical framework which guides you about all the things you...

by Pete R.
Ensure quality in your user stories - the INVEST-Principle

Ensure quality in your user stories - the INVEST-Principle

The INVEST principle allows teams to work effectively on a good user story. To understand INVEST better, one has first to understand what the mnemonic stands for.

by Pete R.
Estimation in the agile world done right! How to play Planning Poker®?

Estimation in the agile world done right! How to play Planning Poker®?

Planning Poker® is one of the tools used in Agile. The reason why it is useful is that it helps the team, decide how many of the points are allocated to a specific story or task. It helps mitigate...

by Pete R.
5 Tips for Dealing with Uncooperative Team Members in Scrum

5 Tips for Dealing with Uncooperative Team Members in Scrum

It is normal to come across people at the workplace that can make your job more complicated than it actually has to be. These kinds of people are disrespectful, harmful or merely unwilling to behave...

by Pete R.
Does Scrum Alone Stand for Agile?

Does Scrum Alone Stand for Agile?

Is Scrum the only technique in Agile? Many people consider Scrum a single method of Agile. Long gone are days when Scrum and Agile were used interchangeably. Nowadays, many people know about the...

by Pete R.
Changes That Occurs When Moving from Waterfall to Scrum

Changes That Occurs When Moving from Waterfall to Scrum

Are you thinking about the changes that occur when a company shifts of Scrum? In today's advanced world, the previous approaches for software development are unviable. Though waterfall practice is...

by Pete R.
Hey Scrum! Where has the test phase gone?

Hey Scrum! Where has the test phase gone?

If one is looking for a methodology to manage programmers, then scrum is their best bet. If one wants to tests cases, they need to give Scrum a try.

by Pete R.
Best Ways to Track Time in Scrum

Best Ways to Track Time in Scrum

Without a doubt, time tracking is one of the many things that a software developer doesn't enjoy. It is perceived that keeping track of time is wasteful and restricting. This is because the time...

by Pete R.
What is the Nokia Scrum Test?

What is the Nokia Scrum Test?

Over a decade ago a man named Bas Vodde introduced a simple test that was able to assess the level of agile adoption and Scrum at the Nokia-Siemens Finland. The test was conducted on almost ten agile...

by Pete R.
Top Signs That Your Organization Is Not Ready for Agile

Top Signs That Your Organization Is Not Ready for Agile

Are you thinking of implementing Agile in your company? Do you think your company is ready for Agile? In the software development industry, everyone is talking about the benefits of Agile...

by Pete R.
Scrum Estimations vs. Request for Accuracy

Scrum Estimations vs. Request for Accuracy

Estimation is something significant when it comes to getting the tasks completed. However, there are cases where an estimate turns out to be wrong during the process. When you start working on a...

by Pete R.
Scrum - your burn down-chart looks strange? These techniques will help you to improve

Scrum - your burn down-chart looks strange? These techniques will help you to improve

Scrum burndown charts might not always seem like the ideal charts that one would want and sometimes, the charts might appear more terrifying than one might have thought. Some people might try to...

by Pete R.