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