[jasongi]

An overblown estimate is arguably just as damaging as an overly optimistic one. The thing about estimates I’ve found is that the actual amount of time it takes to complete a task will never shrink to match an estimate, but it almost certainly will grow to match an estimate.

The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand.

[x86x87]

You do understand that an estimate is not a guarantee and should not be treated as one, correct?

Planning poker is a sham. Between the abilities of variours sw engineers, their experience level and the knowledge in the area that needs to be touched almost any estimate can be given. In really it's just a way to create peer pressure and extract more value from people.

[ozim]

Some peer pressure can be good for the team/people.

[distcs]

> 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.

[pmg102]

I'll have a go:

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"?

[HeyLaughingBoy]

> 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.

[bavell]

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.