Planning Poker

As you know, I have recently been doing a lot of exploration on how to run better retrospectives. So far, the team are linking what I have tried and any improvements that we come up with are actually being completed. In doing this, my main gripe is starting to be corrected with each and every sprint.

However, I started picking up another issue. After our retrospectives, we often do our sprint planning where we look at the backlog of items and decide how much effort the tasks would take. Typically what would happen is that one person would give their estimate and the rest of the team would just agree with it. In my opinion, this made the estimates largely useless as the team members didn't apply themselves in thinking what the work actually entails. They just went along with the flow.

In my previous projects, I had always heard of people suggesting we do some form of planning poker, but again, nothing was ever done about it. So I started doing some investigation into how it works and if it would be able to benefit the team.

Why Do We Need It?

As in retrospectives, what I was trying to avoid is the Groupthink phenomenon, whereby people are easily influenced by what other people say. You want people to think through the problem on their own and try identify what the various components of the system are that need to be modified or created.

In doing this, you get more heads on the solution which brings up various points that need to be taken into consideration. This, in turn, leads to better estimates as you have taken multiple factors into account. Just note, that this won't give you perfect estimates, but it will make them a bit more accurate.

How Does It Work?

In a Planning Poker session, each participant is given a deck of cards which have numbers on them, such as 0 (A few minutes/already done), 1, 2, 3, 5, 8, 13, 20, 40,100 a ? (Unsure) and ∞ (The task is to large to estimate) which represent story points.

The facilitator will then take a backlog item and explain what is required in order to complete it. The team is then given a chance to ask any questions & ensure that they know exactly what the task entails. Once everyone is happy, the team members independently decide on the level of work and determine the amount of effort required. Once everyone is done deciding, they all show the estimates at the same time. If there are any people with high or low estimates, then they need to explain their thinking and rationale behind their decision. The team can then discuss any points that may been risen and then re-estimate the task until a consensus is reached.

As time progresses, the estimations will become easier to make and you will start to learn how many of these points can be completed in a sprint.

Things To Remember

Below are some tips & things to remember when using planning poker. They are meant to help guide you and hopefully prevent you from falling into some common pitfalls.

  • If large numbers are chosen (> 20), then this is an indication that either the work is not understood, or that the task is too large and needs to be broken down.

  • Don't average the different cards that are chosen. You want people to discuss and challenge each others thinking. Averaging the numbers allows people to quickly settle on a value and carry on, which may cause some important information to be missed.

  • Only allow the people who could do the work to vote. You don't want people who have no idea on what is involved to complete the task to provide input as this will skew the results. This also applies to managers or product owners, as they often want the task to be completed in the least amount possible and completely disregarding the work involved.

  • Try to limit the time of the discussions, you don't want everyone's energy wasted on a particular task.

  • Related to the above topic, if the teams can't come to a consensus after three votes then choose the largest value and move on. As was mentioned above, you don't want to waste people's time and energy on one task.

  • Establish a baseline so that everyone has a reference point as to what the various sizes of work are. You can take some previous stories and group them into small (3 points), medium (8 points) & large (20 points). In order to do this, you need to make sure that everyone has a good understanding of the tasks chosen. In addition, try to keep the baselines recent, as over time the actual effort of tasks may be forgotten. In saying this, it is important that you keep the magnitude of the points consistent so that you don't develop "point creep".

  • Don't equate hours to story points as the hours a task takes will be dependant on whom does the work whereas story points remain constant no matter whom does it.

I'm going to be trying this out over the next few planning sessions to see how it goes and what the team thinks about it. If you have any ideas on improvements, or things that you have done before that you liked, leave them in the comments section below.

Until next time...keep learning!

Mauro Da Silva

Learning everyday about software development, leadership & self improvement

South Africa