Planning Poker is certainly a fun and engaging way to do one of the most boring things on earth (STORY POINT ESTIMATION.)
If I’m not wrong, James Grenning originally came up with this idea. And my understanding is that Planning poker can best be explained by using fundamental premise of Wisdom of Crowd (Why the Many Are Smarter Than the Few). Jack Treynor’s Jelly Bean Jar Experiment is a classic example. The average guess of the group is better than the best guess of any individual.
Can we apply this concept to software estimation? May be. But there are a few small difference. In the case of the jelly bean experiment
- Everyone in the group is taking their best guess.There isn’t much prior experience or historical data to look at.
- There is zero consequences if they go wrong. They will not be held liable to this number.
- Also, everyone, more are less, are equally good at the task at hand (counting.)
Now when we talk about applying the same to highly specialized software development where each skill is quite diverse and the involvement of each person is quite varied. What do we get? A complete mess IMHO!
One way to address this issue is to embrace the generalizing specialist approach. If nothing else, in the long run, these folks would become great assets to the company.
But if you don’t want to go down the generalizing specialist route, and you have people in silos with deep pockets of knowledge/skill, can planning poker work? After trying it for 3-4 years, I did not seen it working. But you should certainly give it an honest try. After all, <sarcasm>its the industry best practice.</sarcasm>
The other argument I often hear in favor of planning poker is that when the teams are doing this, they learn so much from each other. I agree 100% to this observation. Certainly getting a group of people together and asking them to estimate (commit) to something, gets them to talk to each other, share their view points and it leads to knowledge sharing. IMHO knowledge sharing is extremely important. Why not have focused meeting for just knowledge sharing? Brown-bag sessions, show-n-tell sessions, code-walk-thrus, idea-fest, scratch your personal itch days, refactoring-fest and many more. Why morph something so important under the estimation/planning meeting banner, where the priorities are different? People don’t go into a planning session saying “Wow, today all of us are going to learn something new.”
Also I would suggest reading my blog on: Story Points and Velocity: Recipe for Disaster.