Personally I find watching paint dry on my walls — or grass grow in my yard — more interesting than watching someone else win at poker, but hey, this proves there is something for everyone!

So what is my point with using Poker Players tonight in my comic strip?

Two words you should become familiar with:

Planning Poker.

There is a lot of great stuff written about this on the web and in books already today.

The first place I’d recommend stopping by is Mike Cohn‘s sites (www.mountaingoatsoftware.com and www.planningpoker.com) and a gentleman named Henrik Kniberg posted something recently at www.crisp.se/planningpoker/

Now.

Regular readers may recall that I am not a big “tool user” or “proponent” of tools for implementing Scrum. This is one area where I take exception. There’s one in every crowd now, isn’t there (smile).

Why?

Please. First, go read the links that I have given you above. Come back.

Back?

Now… did you read the Divinci Code? One of the cool things brought out in that book was something called the Fibonacci Sequence. Check it out // google it if you do not understand it. Basically it takes the number before and adds it up to the next number, to look something like this:

0, 1, 1, 2, 3, 5, 8, 13, 21 etc…. (or something pretty darn similar!). The key here is that the numbers go start going up pretty quickly.

You can use these numbers to help do something called “relative estimating” when coming up with your Product Backlog. Remember the difference between the Product Backlog (constantly changing) and the Sprint Backlog (the work the team has pulled off the Product Backlog to work on during this iteration!).

Use Planning Poker to help come up with relative estimates for the size of your Product Backlog.

It can tell you some sobering things about what it is you are working on.

Remember, with Scrum (in this blog entry at least), the goal is for a team to produce working software. And, it would be awesome if the team could do this in iterations that continually build upon the past iterations and bring money / customers into your business to help pay for even more development efforts.

The rules are out on the various links I have provided, and they are pretty straight forward.

Read them. More. Really. I can wait.

Now….

Here are some ideas I find useful when playing Planning Poker.

First. Make sure the Product Owner is there. If the Product Owner is not present, skip this exercise. Guess what… doing this exercise without the Product Owner can bring back memories of how some of us used to try and develop software… by making assumptions for the Product Owner or customer. This can be bad. So do not proceed without one present.

Really.

Next.

Time box this exercise. When it says one or two minutes per topic, stick to that timeframe. Really. Otherwise you get into analysis paralysis and start going down possible political mind fields or rat holes you have no interest in jumping into.

Next.

Finish it in one sitting. Trust me.

Next.

Do not. Do not. Do not hold one “user story” as the “gold standard” of cards. Remember this is relative estimating. And um…. estimating is used as the world for this because well, that is what it is (smile).

Next.

If some of the team votes a 5 on a story while others vote an 8, make a team norm that says go with the higher or lower number and just move on. Statistics has proven (thankfully) that in the grand scheme of this thing we call estimating…. guess what…. sometimes a 5 takes as long as an 8 and wow, sometimes an 8 takes as short as a 5. In the end, it evens out.

Next.

Do not panic when you add up your numbers and it looks like hell will freeze over before this project will ever get done.

Guess what.

It is what it is my friend. You are sharing data that was not there in the past.

Does this mean go out and try to screw with the iron triangle? NOPE.

Does this mean you’ve got to get better tracking your Burndown Chart? Possibly?

Does this mean you’ve gotta start having some tough conversations?

Most likely.

As strange as this “game” may look to outsiders, I have personally used this technique with multiple teams around the world with a ton of success.

Is it easy to do?

Who said it should be easy?

Remember as a ScrumMaster or even as a member of a Scrum Team, Scrum exposes though things sometimes. You have to deal with them and not hide from them.

Move on.

And develop working software.

By the way… when you do not follow some of the simple advice I give in this blog entry, feel free to contact me to come in and help with it; I am amazed that people actually pay me to come in and help “fix” some of these types of problems. Don’t get me wrong… I love what I do and enjoy the fact that I can make a living working with teams that truly are interested in what I can offer to help (thank you to all my current and future clients!).

Gotta run….

Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!