People who promote the use of Planning Poker understand some of the main reasons why it is successful.  People like Mike Cohn have been very instrumental in pushing planning poker and even created www.planningpoker.com for people to be able to play planning poker with distributed teams.  There are very good reasons why most agile trainers and coaches (myself included) promote its use. 

My personal top 3 reasons planning poker is great are (all of these assume the team is using planning poker appropriately):

1. Fosters collaboration by engaging entire team
2. Creates consensus estimate rather than having a single person driving the estimate
3. Exposes issues early through discussion of each user story

All of those are great reasons to use planning poker, but there are also some ways to help make it work even better.  The three items listed above are all very obvious if you watch successful teams using planning poker.  But there are small things most people miss which can be done to improve the process.  Knowing of those things allows successful coaches to help teams get even better.  The beauty of it is you don’t have to be a coach, just someone the team trusts, to help the team get better.  So what are these nuggets of wisdom?

1. Those who actually could do the work are the ones that vote.  Too often agile teams have everyone vote even if they have no idea about the work involved in the story.
2. Managers don’t vote.  Managers are usually incented to have the work take less time, so they often skew the vote too low.  However, managers have more experience than the average team member, so I usually give them veto power over the team consensus in one specific circumstance – they can ask the team if they have considered something which may INCREASE the size.  They are never allowed to try to get the team to decrease the size.  Their opinion carries too much weight and acts as an anchor to the size, dragging it down in direct propoportion to how vigorously they defend their position.
3. When there is a tie in the voting between two sizes which are consecutive, just pick the larger size and move on.  Remember, consecutive sizes might be 5 and 8 if you are using the Fibonacci sequence for sizing (1, 2, 3, 5, 8, 13).  No one should complain about using the higher number and an equal split usually takes a long time to resolve.  It also usually resolves to the higher number, at least in my experience, so let’s use those facts to our advantage and move on.
4. 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 to a certain extent, but it should be severely limited.  No more than a one minute discussion.  The people doing the sizing should determine in their mind the simplest possible solution and pick a size based on that scenario.  It seems like more discussion will make the size more accurate, but in reality this just isn’t true.  The scale is not very granular so there is a distinct lack of precision.  This is done partially to encourage teams to just make their best guess and move on.
5. Use an “I need a 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.
6. Use a timer of some sort to limit discussion.  This is self-explanatory.  I usually like to limit discussions to no more than one minute.
7. If consensus cannot be reached by the end of the third round of voting pick the largest size and move on.  After two rounds of discussion further discussion usually does not yield great results for the time invested.  By choosing the largest size the team has a chance to improve upon it, but they will not be in any danger of not having enough time.  Not having enough time is a major problem the team is trying to avoid, so this particular short cut should not cause major issues.
8. Have the person creating the user stories meet with QA and Development leads prior to playing planning poker to make sure the user stories have answers to the most obvious questions the team will ask.  This allows the team to focus on the size, not spend time gathering information.
9. Remember the baseline.  Whatever the team picks as a baseline needs to be consistent from iteration to iteration.  If an ideal day is a size 1 then all iterations need to use that reference point.  If a particular user story is a size 1 or a size 3 then that needs to remain consistent across iterations.  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.  Failure to do this could lead to what I’ll call “size creep” over time.  In other words the team slowly changes their baseline mentally to be either larger or smaller than it truly is.  This usually shows up as the team not being able to meet their commitment for several iterations even though everything looks more or less the same.
10. Have fun!  Playing planning poker should be a fun, collaborative exercise.  Too many teams try to grind it out for an hour or two and forget to enjoy their work.  There are many ways fun can be injected into the process.  One I particularly like is to play real poker with the sizes.  Every sized story counts as a poker card and every five stories makes a poker hand.  Prior to starting everyone tries to pick which hand will be the best poker hand (i.e. pick hand 1, hand 2, hand 3, etc.).  This encourages them to look at the user stories ahead of time so they can try to make a good guess about which set of 5 will make a straight or 4 of a kind.  Winners can even get a small prize.

Give these tips a try and see if they help your team.  Until next time I’ll be Making Agile a Reality™ by helping teams play planning poker!

An expanded version of this blog entry appeared at the Agile DZone http://agile.dzone.com/articles/introduction-planning-poker.  That article has now been translated into Japanese and can be seen at http://pub.ne.jp/Under_the_Bridge/?entry_id=2762950 (thanks to Tetsuji Maegawa for the translation!).

Related posts:

1. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
2. Holistic vs. Dogmatic Agile Definition – Results Matter! I originally wrote about this topic in our September email newsletter.  In...
3. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...

I’d be rich if I had a nickel for every time I’ve heard this, or something very similar to it, in the past 30 years!  Alright, that’s taking it too far, but I think I could at least afford a really nice dinner out with my family on the amount I’d have received.  But that isn’t the point.  The point is anyone thinking this statement is a valid excuse for poor results is wrong on several fronts.

Before we go any further, if the title intrigued you, immediately click on the image to the left and purchase Mike Cohn’s bible about agile estimating and planning!  If you don’t own this book, then I now know why the title of this blog post made you look further! 

Now, back to the issue at hand and why it is wrong to think this way.  First of all, this type of statement is part of the reason a waterfall model doesn’t work.  In the waterfall model it is typically development leads or other managers giving the time estimates.  This isn’t a written rule for a waterfall approach, but it seems to be given how often I have seen it in my career.  Let’s think about it for a second and see why this is the wrong way to approach things.  Is the development lead rewarded when a lot of software gets completed?  If so, this incentive is at least subliminally causing them to cut time estimates to the bone.  Is the development lead more experienced than most members of the team?  If so (and I hope the answer is yes!), then he or she is likely to estimate for their rate of development, not the rate of development for an average team member.  Does the development lead have enough clarity to actually give a meaningful answer?  If yes, great, but in most cases the answer is no.  Again, this leads to an estimate which may be on the low side due to a lack of knowledge about specifics.  So just from a logic point of view, using a model where the development lead estimates time is bad.

Second, on agile teams some goals are to collaborate well, and be held accountable for results.  If this is true (and it is), then we are completely bypassing both of these.  We are not allowing the team to collaborate to come up with an estimate they can live with.  Further we are holding them accountable to a result when they were not given the opportunity to give input.  We are back to waterfall where someone says we need x by date y and I told with Joe and he said we could do it, so do it.  That isn’t agile, that’s lunacy!

Lastly, we have taken a single data point and assumed it is 100% accurate at the start.  Even in a waterfall project it is well known that accuracy of estimates at the beginning of a project vary widely.  Review the cone of uncertainty to learn more about how bad it can be.  Part of our goal in agile is to deal with the cone of uncertainty by iterating toward a result.  So to add insult to injury, we assumed the estimate was correct, and we didn’t check on it each iteration to deal with reality.  How not agile can you get?

Project managers are starting to recognize that estimating is different in agile.  This blog post from PM Toolbox is just one example.  There are many more things to consider when estimating.  For example, things sometimes get more difficult at the end of a project (or at least development slows down).  There is a reason the 80/20 rule is often cited!  There are lots of ways to estimate, and lots of ways to do it poorly.

The bottom line is the worst thing anyone can do is ask a development lead to estimate something and then hold an agile team accountable to the estimate.  Collaborate and use planning poker to create estimates and you will be a lot happier in the long run.  There is even planningpoker.com for teams that are distributed! 

Time for me to get ready for a trip to Boston where I’ll be starting down the path of  Making Agile a Reality™ for another client.

Related posts:

1. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
2. Why Unit Test-Driven Development is Important People have written a ridiculous amount about the advantages of test-driven development. ...
3. Agile antipattern: Comparing velocity between teams I recently saw an excellent blog post about iteration velocity.  Good reading...