Planning Poker: Software estimation for fun and profit

January 31, 2008


Ever since hearing about Planning Poker (an excellent description is here: http://www.planningpoker.com/detail.html) I’ve wanted to try it out with my team. We started holding twice weekly planning poker meetings back in August 2007, and now, approximately 30 meetings later, we’ve established a good system.

We have adapted the rules slightly from what is described in the link above.

The process is:

After the meeting, I compile the estimates for all of the items into a project schedule, add some time for testing and deployment, and then run it by the project team for a “gut check”. For example, “These estimates have us hitting Milestone 1 on Friday, Milestone 2 next Wednesday, and then finishing the project the Tuesday after that. Is that reasonable?”

The Deck of Cards

Each person has a deck of cards with ‘1 hour’, ‘2 hours’, ‘1/2 day’, ‘1 day’, ‘2 days’, ‘Breakdown’, ‘Needs Design’.

Each person votes by throwing down one card. We decided that we didn’t need to get very granular in the task breakdown because who really wants to argue over whether something will take 10 or 11 hours.

‘Breakdown’ is used whenever you think something will take longer than two days. This signals that we need to break the item into sub-tasks and estimate them individually.

‘Needs Design’ is used whenever more information is needed before an item can be actionable.

Short Circuiting

We have invented two new rules to speed up the process.

Rule: The ‘Needs Design’ card can be played by anyone at any time without waiting for voting.

We put this in place because when an item needs design, discussions around it have a way of being very long and circular. This rule gives anyone in the meeting the power to recognize this and prevent a bunch of wasted time.

Rule: You can skip discussion of an item by saying, “I think this will take 2 hours, assign it to me.”

The Benefits of Planning Poker

Planning Poker has a lot of obvious and non-obvious benefits:

I’ve tried to gather software estimates in a few other ways that don’t work as well. Each one has a few fatal flaws, for example:

« Back