On the Yahoo APM group Alan Baljeu asked the following question:

"Following the "Head First" book, they suggest a game of planning poker where disagreements between two developers help weed out assumptions in making the estimates, to get more realistic numbers. I'm the only programmer type around currently, so this doesn't seem to be very effective. Suggestions?"

and I offered the following answer:

"You certainly will find it challenging to make use of the convergence and consensus aspect of estimating this way if it’s just you all on your lonesome – however you can still use the sequence that is on the cards.

 ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40

This way you will still gain some advantage – for example if you think something might require 6 days/points of coding apply it to the sequence and take the next highest number which is 8 – then plan 8 days/points for that task rather than 6. This will give you some safety in your estimates when they are larger than 3 days/points.

Also, if you find you have too many that force you to choose 20 or 40 you should reduce the complexity of these tasks or reduce them down to subtasks until you have nothing larger than a 13.

But don’t give up on getting a consensus – if you can identify a product owner – or if you have a tester – play poker with them. To begin with this will seem like it’s a waste of time – however after several games and iterations of work you will all learn how much time it takes the team to do something rather than how long it takes you to do something. Imagine the product owner thinks its simple so he plays a 2 because all he has to do is write some rules, you know you need to learn something new so you play a 5 and the tester plays a 3 because be wants to be through. If you have the game and you play these cards you will still have the conversation about why you played the card and learn something about each other. Next time you play the numbers will converge because of the greater understanding about the team’s task."