Ran across an interview at InfoQ about using poker playing to help with software estimation. Looking at the planning poker site, it seems a bit gimmicky and hokey and reminds me a lot of the the CRC cards approach (BTW, I think my next job title will be agile consultant). I have never really done a project using CRC but I don’t think that I, or most of my co-workers, would have the patience for it. Same thing goes for the poker planning idea.
I’ve never found getting estimates to tasks to be that big of an issue when planning projects. If you can break tasks down into reasonably sized chunks, I find that good developers are usually pretty good at determining how long it will take. The big problem with planning projects is trying to prioritize tasks and determine what needs to go into each release, not so much the estimation of how long it will take.
All that being said, I think Tim McCune would love it. Maybe he can get Yahoo to adapt it.
Popularity: 7% [?]
Some developers are pretty good at estimating. Others are pretty horrible. What’s kind of sad is that, for whatever reason, it’s really really hard to teach those who are bad at it to get better.
I’ve also worked with some “problem child” developers, who simply refuse to estimate at all. When pressed, they just say “2 weeks”, but you know it’s BS, and you know they just don’t care.
We actually have used a simple version of planning poker on my team at Yahoo, and have found that it did improve our estimates, and the team liked it pretty well.
It helps for the same reason that code reviews help; the collective works better/smarter than the individual. If it doesn’t, you should fix that problem before you worry about anything else. 