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...

James Shore recently changed the entire focus of his company. This blog entry gives his reasons why. The blog post really struck a chord with me because I often use the phrase “To me mediocre is not acceptable.” Now I’ve found someone that agrees with me!  To me there is nothing worse than seeing a team not reaching their full potential because they are unable to see the problems they are causing themselves.  In fact, some teams even laugh about it when it is pointed out to them!  Grrr, don’t let that happen to you.  Read on for some things to watch out for.

There are many ways mediocrity can appear and seem harmless. If you are new to agile, here are a few that you need to be careful about.

• Daily stand-up meetings taking more than 15 minutes
• Team members being late to meetings
• “Just a little” testing not completed within the iteration
• Not inviting users, customers or stakeholders to iteration demos
• A retrospective where no action items for improvement are created
• Decreasing the committed scope of an iteration
• Team members not working on stories in priority order
• Boring daily stand-up, retrospective or planning meetings
• Defects regularly being found after an iteration is completed
• Iteration planning taking forever because the Product Owner is not ready
• Lack of release planning
• The big picture for the project is never made clear

There are many more things which could become commonplace and accepted.

DO NOT ALLOW IT TO HAPPEN!

Once you allow mediocrity (or worse!) to occur once, it suddenly becomes accepted behavior.  Do yourself and your team a favor and insist mediocrity is not acceptable!

Until next time I’ll be standing my ground on this issue while Making Agile a Reality™ for my clients.

Related posts:

1. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
2. Agile antipattern: Doing Agile! I spent the past week in Orlando, Florida  at the Agile Development...
3. New to agile? Give thanks! Here in the United States we will be celebrating the Thanksgiving holiday...

I was just working on some Powerpoint slides for our Agile Product Management Boot Camp coming up on March 9 and 10 and I realized I should post a blog entry about the point the slides are making.  Actually, I’m trying to make two points with the slides.  The first point is we tend to work in organizations where the phrase “everything is priority 1″ is common.  The second point is my personal distaste for using the phrase “prioritized product backlog.”  I’ll cover each of these points separately.I’ll start with the “everything is priority #1″ problem, since that is the title of this blog entry.  Let’s be very clear THIS CANNOT BE ALLOWED!!!  There are many blog posts on the web such as the ones here and here.  I like what the first of those links says about how to explain why everything can’t be priority 1 – we can’t build it all at once!  I usually approach this with product managers/product owners/stakeholders by asking them what they want if they can only get one thing.  They quickly say one thing is useless they need it all.  To which I reply, I know, but I want to make sure we have the most important item built first so we can learn from it and make changes to other items based on what we learn.  I’d like to rank all of the items 1 to whatever, with no ties, so we can always be working on the next most important item and be able to learn from it as well as all the other items which were more important.  This way we will make sure the most important items are in the release and meet expectations.

Which leads into my second point about the phrase “prioritized product backlog.”  If you simply say the words, nearly everyone in the software industry will say  they already do that.  Why are they saying this when a casual observer can tell it isn’t true?  It is because we have overloaded the word prioritization.  Most software people think having a list of 100 items which has the top 97 as priority 1, the next 3 as priority 2 and no priority 3 items is a prioritized backlog.  Sorry folks, but that is a useless list.  We really need a RANKED backlog, where the rankings go from 1-N and there are no ties.  Then we use the list by making sure we work on the next item in the ranking, not just work on some random thing which seems interesting.

We simply have to keep these two issues in mind when we are dealing with the product backlog or we will not be successful.

So, what do the two slides look like?  Here they are:

This is the first post in the “Agile Antipattern” category.  I anticipate having a few more over time.

Until next time, let me know what you think so together we can be working toward Making Agile a Reality™.

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. Agile antipattern: Sizing or estimating bug fixes Is the bug to the left a large bug or a small...
3. What do you want next? The software industry today is plagued by long release cycles for important...