Are you still playing poker at scrum planning
“How does your team do estimate in sprint planning?”
I asked a new manager.
“Oh, we are doing scrum process by the book: we play poker with Fibonacci numbers, we discuss then we play again to reach concensus.” answered the manager proudly.
“Did it work?”, I was curious.
“Pretty good! It used to take forever to agree on a number so we have a rule that the highest number in the second round will win. We know that is biased towards team members with less experience. But we at least allow each member to voice their opinion. Democracy is good, right?” He said.
“Then how do you assign tasks to team members?” I asked.
“Ah… that is the problem” he sighed, “People naturally pick the interesting tasks first for themselves, we have to rely on tech leads for the perceived ‘boring’ tasks, like fixing broken integration tests, security policy violations etc. Team leads complain this is not fair. Democracy does not guarantee fairness I guess.”
“And how do you think the efficiency of the process?” I asked.
“Good …” the manager is not that sure anymore, “at the end of each sprint, the few experienced, hard working team members tend to contribute 80+% of the completed points.”
“Well. It sounds like the dilemma of communism, isn’t it?” I laughed, “It is equal, but not fair, nor is it efficient!
I’ve ran into teams in crisis several times where the manager made an announcement: ‘we are doing scrum wrong!’ So the manager had the whole team do a fresh round of scrum training and we started playing poker.
Did it work? Well the manager turned out to be the problem. Once they were gone, things got better. No process can cure people’s incompetence.
We incorporated many elements of scrum process into our software development processs: in many ways these were common sense project management best practices that have been used for many generations in other industries like construction, but scrum formalized the terminologies.
But I don’t think playing pokers ever worked for us. It only promoted mediocrities, instead engineering excellence. The idea of a crowd throwing in numbers will get better estimates than the individual subject matter expert is predicated on the assumption everyone in the crowd have the same amount of expertise, and they will vote rationally. But that is rarely true. Human, in fact almost all organic systems are naturally hierarchical. There will always be members more experienced, more skilled and more dedicated than others. Your top performers will be 10 times more productive than your p50.
So my advice: pick the elements that are useful to you team from scrum, kanban, six sigma and lean, whatever works for you. Don’t worry about you are by the book or not. Nobody is by the book, the statement itself is against the agile manifesto.
But don’t play poker in planning!”
Last updated
Was this helpful?