Ever since hearing about Planning Poker 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:
- 15 minutes before the meeting begins, I set up a room so that Jira (our issue tracking software) displays the list of pending items on the wall through and a projector.
- Anyone who is not engaged in some sort of urgent activity files in (usually between 5 and 8 people).
- Everyone grabs a deck of cards, described below.
- Starting with the first item, the person who knows the most about the item gives a brief description and calls out any ‘gotchas’ that may be involved. This takes 5 to 7 minutes.
- Once discussion starts to die down, either I (or whoever is leading the meeting that day) or the person describing the item says, “Ready to vote?”
- On three, everyone throws down a card from their deck of cards (Details below).
- If the estimates are wildly different, then the two people with the lowest and highest estimates describe their thoughts, and we revote.
- If the estimates are roughly the same, we’ll settle on one and update Jira with the estimate.
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.
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:
- Everyone has well-defined, scoped, immediately actionable items assigned to them (GTD-ers should see the value in this)
- Schedules are more trustworthy
- The discussions spread historical knowledge about the system
- The discussions keep the team informed of changes happening to the system
- Junior team members learn how to calibrate their estimates
- All team members grow more confident in their estimates
- The person doing the work has a voice in the estimate
- The estimate feels fair, and the process is transparent
- Because the estimate is fair, you feel healthy peer pressure to meet your schedule
- The team gets a good sense for how difficult a task will be
- When someone takes on a difficult task, the whole team knows it and appreciates it
- Guards against “optimistic” estimates that are way to low
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:
- Having one senior person estimate items for the whole team puts a lot of pressure on the senior person, and also leads to resentment if the estimates are too low.
- Having a junior person estimate their own items usually results in the person either estimating wildly high and losing the confidence of their coworkers, or estimating wildly low and screwing themselves with an unrealistic schedule.
- Function Points (http://www.functionpoints.com/) are complicated and time consuming.
Content © 2006-2019 Rusty Klophaus