Estimating the complexity of a task, the time needed to complete it and it’s combined risks are an inherent part of the Scrum process. Planning Poker is considered by some Scrum teams as an ideal approach for all estimations.

It doesn’t matter to them if they have to estimate one big task with many subtasks, twenty average tasks or the whole plan for the next release (which might contain over a hundred of tasks). Planning Poker will always be an ideal solution. But is that statement really true?

This estimation method was first defined in April 2002 by James Grenning. 

How does Planning Poker work?

There are many variations of Planning Poker rules, they all have some common parts but they can differ. The following describes the stages as we see them in Setapp. 

1. Examples Stage

At the very beginning of Planning Poker, we create at least two examples. We do this by picking two tasks from the previous sprint.

The chosen tasks should be those which were finished without any major problems and which should differ radically in complexity, in order to aim for one small and one big task.

Let’s say 2 Story Points (usually 2 SPs can be one day of work, right?) and 13 Story Points. If we cannot (or do not want to) estimate based on the previous sprint then the team should go through all the tasks and choose one which has the least effort and one which has the greatest effort required. Then we can start the session by estimating those two.

2. Estimating a tasks stage

We estimate one task at a time. Then we go through the description of this task, which should be the correct user story. After reading and acknowledging the description we can start estimating the task.

Every developer picks one card from his pile and puts it at the front hidden. When everyone is ready the developers show their cards. If there is no agreement then the developers should discuss the differences and repeat voting until a common agreement has been agreed. 

3. Repeat stage 2 for all tasks.

Btw, we are looking for a Scrum Master. If you are up for the challenge then send your application now!

Why are Planning Poker cards in the Fibonacci sequence?

Planning Poker cards are not exactly arranged in Fibonacci sequence but resemble something like it. The Fibonacci sequence is a sequence that starts from 1 and then each number following is made by adding the two previous numbers. For example: 1, 1, 2, 3, 5, 8, 13, 21, 34…The reason for using such sequence is the cone of uncertainty.

This means that the bigger the task the bigger the uncertainty might be. So when a developer thinks that a task should be estimated to 10 SP he should rethink this, so he either decides that uncertainty doesn’t exist or gives it more points.

When we should and should not use Planning Poker?

One may say that Planning Poker is ideal for estimating many tasks and to provide very accurate estimations. Someone else may point out that discussion and elaborative arguments in bigger teams often take more than 15 minutes per task. Overall it is good not to only focus on one planning method. Some other estimation techniques you can use are Swimlanes or the Team Estimation Game.

All in all, I think that Planning Poker is a very good way of estimating tasks, but you should consider some other techniques like Swimlanes when:

1. You are estimating a whole release with hundreds of stories.
2. You are in a big Scrum team (6-9 developers) with many individuals

Tips and tricks

I would like to finish with some tips and tricks that you might consider as useful.

1. If you don’t own a pack of Scrum cards then you can make your own, simply by writing down numbers on small pieces of paper.
2. During estimation always compare the estimate of the task to other already estimated tasks. This might help you spot the inconsistency.
3. The team should have a consensus on the estimation but that doesn’t always happen. Sometimes the discussion gets stuck, no new arguments arrive and developers still don’t change their estimates.
   We need some kind of backup plan for such situations – so decide up front whether you will pick the average in such situations or proceed with excluding one highest and one lowest estimate. I personally suggest using the median and cast it to the closest value we have on the cards.
4. Have breaks. You will often see people getting tired after a couple of tasks, don’t continue estimating and take a short break.