Understanding Planning Poker
Posted at 08:00 on 16 December 2010
We’ve been using Planning Poker for a couple of months now in our sprint planning meetings, and on the whole it’s been quite a success. If you’ve never come across it before, Planning Poker is an estimation technique that’s been gaining popularity among agilists recently: it’s not only surprisingly easy and accurate, but it’s also really good fun.
The procedure is as follows. Each participant is given a deck of numbered cards in the first few elements of the Fibonacci series: 1, 2, 3, 5, 8, 13, and so on. One developer chairs the meeting, and a project manager comes along to explain the requirements for each task that needs to be tackled. The developers then discuss what is involved and break the task down into sub-tasks.
Once the task has been broken down in this way, each sub-task is taken in turn. Every member of the team selects a card indicating how long they think it will take (in our team, we measure it in hours, though some teams use somewhat more vague units of measurement). They place it face down on the table, then once everyone has selected their estimate, they all turn their selected cards face up at the same time.
Sometimes, there will be a consensus; on other occasions, there may be one or two dissenters from the majority opinion. In this case, the dissenters are asked to justify their estimates to the rest of the group. If the estimate comes to more than eight hours, the group then further divides that subtask in to smaller tasks.
The “poker” element is a great leveller. It means that the discussion isn’t dominated by the most dominant, or the most senior, member of the group. It means that the introverts are brought into the discussion. But there are some points that some people seem to have difficulty understanding.
First, proposing actual estimates while breaking down the task is strictly forbidden. The time to make your estimate is when you come to put down your card, not before. There is a good reason for this: if you start quoting figures, you will be “anchoring” the estimate and influencing your team mates. Even if they consciously ignore what you have to say, they may subconsciously alter their estimates to bring them into line with yours, whereas they may otherwise have taken into consideration factors that you hadn’t thought about. Of course, if you actually want to influence your team mates in their estimates, you have no business whatsoever doing so. The idea of planning poker is that estimates should be made on the basis of evidence, not subjective opinion. If you do have a strong opinion that differs from the team consensus, you will be given a platform to justify it after everyone has revealed their cards.
If people persist in proposing estimates prematurely, it might be a good idea to institute a “penalty box” into which offenders would be required to forfeit, say, 50 pence per violation, which could then be donated to charity.
Secondly, don’t get too hung up on the accuracy of your estimates. Planning poker uses the Fibonacci sequence for a very good reason: your estimates will be subject to an uncertainty of perhaps 50% or more. Some estimates will be too small and others will be too large, so in the end of the day it will all balance out. Four is not an option because it is well within the uncertainty range of both three and five. Similarly, don’t get into an argument about it: that just wastes time. Besides, if you can’t come to a consensus for a task within about a minute or so, you’ve probably not broken it down clearly enough.
Finally, even if the details are wrong, the estimate may still be right. A few weeks ago, our team estimated for one particular task using Planning Poker when I was on holiday. Since I had the necessary domain knowledge for this particular task, I ended up working on it when I returned. They got the implementation details of the task concerned completely wrong when estimating, but incredibly, the time that I took to complete it turned out to be within about five percent of what was estimated.