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?