planning poker

Agile Estimating Tool – Planning Poker using Fibonacci Sequence

The best we can do is size up the chances, calculate the risks involved, estimate our ability to deal with them, and then make our plans with confidence – Henry Ford

H

ave you ever tried to estimate the size of your user stories ? There are a lot of methods in order to get this result; two examples are “Ideal Days” or “Ideal Hours” and “Planning Poker”.

In this article we’ll deal with the “Planning Poker” estimating tool.
This method of agile estimation can use a modified version of the Fibonacci Sequence.

Fibonacci Sequence

 
It’s the sequence where each number is the sum of the previous two numbers
 

e.g. 0,1,1,2,3,5,8,13,21,34,55,…

The method is based on an estimation technique known as “Wideband Delphi”, which was created by the RAND Corporation in 1940 (some sources states that the right year was 1968 but that isn’t really important).
The technique was refined by James Grenning in 2002, making it much more usable by agile teams.
 
Using the numbers in the sequence leads to the outcome of calculating story points, that is the size of the user story.

A tip to make the technique more effective

If we had a task, and tried to estimate how large it was numerically, that could be incredibly difficult. What’s your standard of comparison? We could assign it any size number we like, if we were not comparing how big it is to anything else.
Using the modified Fibonacci Sequence to establish a scale and do relative sizing can make our estimations more accurate and now we’ll discover why.
 
Here are the ground rules.
 

Let’s provide the team members a deck of cards

Planning Poker Cards

Planning Poker Cards

Each participant gets a deck of estimation cards representing the Fibonacci Sequence.
 
Here’s how the modified sequence goes:
1, 2, 3, 5, 8, 13, 21, etc.
 
The unmodified sequence starts with 0, 1, 1, 2. We don’t need a size zero, which implies that the user story is non-existent. We also don’t need two ones since they are both the same number.

Presenting the user story

The moderator presents one user story at a time to the team and the Product owner answers any questions the team might have about the story.
 

Estimating time

Each participant selects a card representing his/her estimate of the “size” for the user story. Usually size represents a value taking into account time, risk, complexity and any other relevant factors.
When everybody is ready with an estimate, all cards are presented simultaneously.

Estimating Time

Estimating Time

 

Establish the baseline for comparisons

It doesn’t really matter what the highest number on the scale is. In most cases, the lowest number will be one. For example purposes, let’s take it easy. The smallest user story is one story point, and the biggest one is 21 story points.
But how do you know which story is a 3 and which is a 5.
In order to do that, we should find a baseline story. It does not have to be the smallest one, but one that all in the team can relate too (it could be the one whose size is 21 for example). From then on, all sizing should be done compared to that baseline.
 

Creating consensus

If there is consensus on a particular number, then the size is recorded and the team moves to the next story.
In the (very likely) event that the estimates differ, the high and low estimators must defend their estimates to the rest of the team.
The group briefly debates the arguments and a new round of estimation is made.
Let’s continue until consensus has been reached and the moderator can record the estimate.

What is a story point?

 
Story point is an arbitrary measure used by Agile teams (most used by Scrum teams). This is used to measure the effort required to implement a story.
 
In simple terms it’s a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.
 
The concept of “story point” sometimes creates a bit of confusion, especially as most of us who come from a PMP background and relate this immediately to hours.
 

Story points do not relate to hours

 
So lets just not compare them. There is another technique called ideal days or ideal hours, which can be used.
The story point is a virtual size not relating to hours or days in a linear transformation.

Take the next user story on the list and give it a number

Is this user story the same size as the smallest one? Let’s give it one story point. Is it the same size as the biggest one? Let’s give it 21 story points. Is it somewhere in the middle? Let’s give it an eight or 13, depending on if it’s closer to the smaller end or the larger end.
 

Repeat the previous steps for the rest of the user stories

Do the same exercise that you just did for the rest of the user stories.
 

Why is it so effective?

There are at least three reasons because this technique can give our projects’ estimations a great advantage.
– it engages the whole team and encourages collaboration;
– it creates and improve consensus;
– it rises issues early through discussion of each story.
 

Tips and tricks

Here are some things you have to take into account when using this technique in order to avoid the most common issues and make our sessions more effective.


 

Only people able to do the work vote.

Let’s choose the right audience. Many people have no idea about the work involved in the story; they shouldn’t be allowed to vote.
This rule is quite obvious, but sometimes we forget about it and our estimates are biased, or worse, homologated.
 

Managers don’t vote

Managers don't vote

Managers don’t vote

Are you a manager? How many times did you think about increasing an estimation rather than decreasing it, maybe reading the planning promise to your client?
Managers often skew the vote too low, so they ought not to vote.
However, managers have more experience than the average team member, so we could give them a sort of veto power over the team consensus, but only in this case – they could talk members into voting again by asking them if they have considered something which may INCREASE the size. They are never allowed to try to get the team to decrease the size.

What to do when there’s a tie in the voting

When there is a tie in the voting between two consecutive sizes, just pick the larger size and move on. An equal split usually takes a long time to resolve and doesn’t take a real advantage or a more accurate estimation.
 

Avoid too deep discussions

Discussion

Discussion

Let’s stop implementation discussions before they go too deep.
Teams commonly drive down to the technical details when they are discussing a user story. This is fine sometimes but we have to limit it to a certain level. The tip here is “no more than a one minute discussion”.
More discussion doesn’t lead to a more accurate estimation, so we shouldn’t waste our time.
 

I need a break

Coffe Break Card

Coffe Break Card

Too often teams will be working hard playing planning poker and not realize some people on the team need a break. Having the “I need a break” card allows someone to draw everyone’s attention to this.
 
 
 
 

Time keeping

Use a timer of some sort to limit discussion.
 

Too many rounds

If we don’t reach consensus by the end of the third round of voting, we have to pick the largest size and move on. After two rounds of discussion, further discussion usually does not take to better results.
 

Baseline

Whatever the team picks as a baseline, needs to be consistent from iteration to iteration. It can sometimes be helpful, after a few stories have been sized, to bring up the baseline and ask the team if they agree the sizes are truly relative to the baseline.
 

Conclusions

If we don’t have a deck of of estimation cards, we could use the online free tool

https://www.planningpoker.com/

It’s a nice way to collect estimations from virtual and not co-located teams (and if we’d like to avoid buying cards).
 
If we’d like to buy decks of planning poker cards, we could get it on the online shop

http://www.planningpokercards.com/

 

I’m an enthusiastic and highly motivated PMP and Prince2 (Foundation) Senior Program Manager with 16+ years experience in the Healthcare industry. I often work in highly pressurized and challenging environments, managing a large-scale software development program up to an order value of €6M. I’m extremely professional in approach and behaviour, adaptable to change, very meticulous, collaborative, energetic, resilient, innovative, proactive and pragmatic. I’m passionate about process improvement, technology innovation, knowledge sharing techniques and how businesses can capitalize on social media integration. My greatest strength is helping to focus my organization’s efforts on the activities necessary to achieve strategic goals and objectives in order to consistently meet both the customer’s and business’ needs; on time and under budget.
  • Pingback: Agile Estimating Tool – Planning Poker us...()

  • Tom Catnach

    Great blog!

    The only think I would add is that if you don’t reach consensus by the third round then do a proof of concept. A quick bit of coding to see just how hard it is. Limit this to one hour.

    Chances are by the end of that hour you’ll have discovered most of the issues & the team will be in a much better place to make an estimate.

Categories

Latest Tweets

How hostage negotiation and project management are interrelated - via @SaverioLosito #pmot bit.ly/1BsfvQK

Donate € 5,00

Help the growth of this blog