Planning Poker - Agile Estimating
by Kelly Waters
Planning Poker is an estimating technique used by many agile software development teams. Like many agile development techniques, Planning Poker is very simple. Simple, but effective.First of all, agile teams should ideally estimate together. As a team. If the team is big, and people are working on different products, it's okay to split the team into smaller groups. But estimates should still be done in groups.
The logic behind this is simple. Each person in the team has different experience. When you get the input of multiple people, you multiply the experience applied to the problem.
The benefit of doing this is based on the wisdom of crowds. You get the benefit of the team's collective intelligence.
In addition, you are likely to generate more ideas. Ideas about different ways of solving the problem. Ideas about how to design the solution. And ideas about obstacles that might be encountered.
All this leads to better estimating. And perhaps more importantly, better solutions.
Here's how it works...
First of all, agree an estimating approach. For instance, many agile teams estimate in points, perhaps using the Fibonacci numbering sequence. Others use T-shirt sizes or some other abstract numbering system. Estimating in an abstract form has several benefits. The key thing is to estimate each item's relative size, compared to other items.
Then, prepare cards with the numbers on. You can buy Fibonaci Planning Poker cards, or make your own. Alternatively you can just ask people to write the numbers you'll be using on post-it notes.
The actual process of Planning Poker is then to discuss each feature in turn, clarifying requirements and asking questions that help to understand how it might be designed. When questions about a feature have run out, or are no longer materially important to the size, each member of the team indicates they are ready to give their estimate.
Then, on the count of three, the whole team reveals their estimate by showing the appropriate card, all at the same time.
As I mentioned earlier, each member of the team has different experience. So it's very unlikely that everyone will come up with the same answer. Maybe someone saw issues and risks that others did not. Maybe someone else thought of an easier solution. The team uses this difference of opinion as the basis for discussion, sharing ideas and concerns.
Following the discussion, the whole team re-votes. This process continues until there's only a small difference, or ideally until the team has agreed on the size of the feature.
Then the team moves on to the next feature, doing the same again.
And that's it! Planning Poker is a very simple but powerful technique, designed to extract the collective wisdom of the team.
For those of you who haven't encountered estimating in points before, I guess there's one outstanding question: How do points make an estimate in time?
The team tracks how many points it can deliver in a Sprint (or iteration). That's effectively their Velocity. Estimating in an abstract form - e.g. points - combined with tracking Velocity, allows a team to understand how much it can usually deliver, enabling it to forecast delivery without the need for detailed planning.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by Kevin Labianco
3 March 2009 14:48
Sounds like a fun activity to get the team communicating.
I'd be interested in how well the technique works in the longer term (once routine replaces novelty). Does this start to become 'process above people' and drive you back down a path to waterfall? Or does the agile culture take wrong estimates in its stide?
3 March 2009 14:48
As a follow-up to this concept, and important aspect of Poker planning is having a good estimation scale: http://agile-commentary.blogspot.com/2009/02/create-proper-estimate-scale.html
4 March 2009 13:38
ref Ed Darnell's question - what happens over the longer term?
Well that depends on whether or not you always play with the same people - if so, over time their experience will become the same so any great variations in initial estimates would be due to different understanding of the issues.
However most teams change over time and the work you are estimating changes so this level of discussion never becomes stale and routine.
In fact we find ourselves using the process more and more.
There is huge value in the discussion and the shared understanding and decisions that this process generates.
We use cards from www.agilehardware.com
4 March 2009 13:44
Ref Ed Darnell’s question about how this works over the longer term.
If your team stays the same, over time the teams experience will gradually become the same. This means that any major variances in the estimates would be due to different understanding of the stories being planned. However, most teams change over time as do the stories that we are working on so there is no chance for it to get stale.
The huge benefit from poker planning is the discussion that goes on before the shared decision is finally made. This all helps the team to be more flexible once we actually start the work – they can help each other out if necessary.
Wrong estimates – well agile is about being able to respond to change and learning from mistakes.
5 March 2009 13:48
I work in a company that employs Agile methods in our development. We have been using planning poker for a couple of years now, and it has proven itself time and time again as an incredibly useful estimating tool.
Hazel is exactly right, one of the biggest benefits from plannign poker is the discussion that results from each round of voting.
20 March 2009 15:34
Nice blog entry. I recently also blogged about something similar. I think the only thing for me to add is that many teams get too bogged down in conversation that can tend to lead to design, detail, or tasking information. To avoid this, show the estimates as early as possible (first responsible moment?) and if everyone's in the same ballpark, move on. This should not be a design discussion, the focus should be on getting estimates (which can/should be refined later if needed).
More detail on this, specifically how Planning Poker creates common understanding in my blog.
http://onemoreagileblog.blogspot.com/2009/03/using-planning-poker-to-ensure-common.html