> The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand.
Planning poker creating a sort of prisoner's dilemma is an intriguing thought. Mind explaining a little how it leads to something like prisoner's dilemma. I'd like to grok the connection between the two things.
If you ask developer A how long it will take, the best outcome for them is that they AND EVERYONE ELSE go high. So they should go high.
BUT if everyone else goes low, but they go high, then they look bad. So they're forced to go lower. But then not too low, or they won't be able to deliver in time.
So perhaps this settles on an estimate that's "as low as possible but no lower"?
> the best outcome for them is that they AND EVERYONE ELSE go high
But it's really not. The best outcome for them is that they are 100% accurate.
Now, I understand that that's generally not feasible, but assuming that you need to pad everything by a huge amount is part of the problem.
As a general rule, I've found that the kind of answer that gets the best response is on the order of "about X time to complete development, Y to get through testing, Z if you need any documentation, release notes or user instructions, I think A, B & C are risk items that could delay completion. If Sally and Jared aren't around for us to ask questions, that will also delay things so we need timely responses from them."
Give good answers and you'll find people take you a lot more seriously.
Very well put and so true. You can exercise much more leverage by exuding professionalism and experience.
I've successfully talked stubborn execs out of bad ideas by framing things in terms they understand (risk, costs, reputation). And by doing so earned more respect which I can further leverage in the future.
Planning poker creating a sort of prisoner's dilemma is an intriguing thought. Mind explaining a little how it leads to something like prisoner's dilemma. I'd like to grok the connection between the two things.