[BlargMcLarg]

>but this is the issue addressed with planning poker.

It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given. This also doesn't take into account turnover and new features being able to remove a team from meeting those prerequisites at any point.

Too often it just devolves into people raising eyebrows at one another and either it becomes 'X will do it, so X's estimate becomes the value' (why even bother doing poker then) or 'take the average or minimum' which screws over anyone who estimated higher.

[IanCal]

I mean it is literally the issue that planning poker addresses - identify differing expectations without influencing the initial estimate. People can then totally ignore that, and ignoring something makes it pointless, but that's true of literally anything.

It identifies a lack of a shared understanding of the task. Or framed differently, it identifies when you probably all have the same expectation and you can move on.

[BlargMcLarg]

That still doesn't solve the prerequisites being exceedingly rare in most teams. A system solving an issue under rare circumstances is barely worth considering, doubly so if it doesn't solve the issue in your specific circumstance. That's, again, disregarding that the modus operandi of most management teams directly interferes with planning poker itself (high turnover, high focus on increasing scope and scope per person).

Or we can dive into technicalities where it technically does solve the issue but does it poorly, and just happens to be better than any other system we know (also questionable).

[IanCal]

I honestly do not understand what you're describing as the prerequisites.

You ask people how hard something is to do, make everyone actually answer before hearing others opinions and if people disagree you talk about it to understand why. These are all short term features.

The two things it deals with are:

* get everyone to say how big of a thing it is, find out if there's misunderstandings about what the task involves

* avoid people from being influenced by the fastest to answer person

That's it. It's a very basic communication tool.

[WJW]

I'm sure that's how it was intended but tbh I have only seen it used in settings where the person in charge would still want to assign a value to the ticket "so that we can move on" even if the devs were not at all in agreement about how big something was. Whoever gets the ticket in the end is stuck with the estimate, even if it was shit from the very start.

[someguydave]

If people are unable to solve the problem themselves but instead defer to someone else’s estimate then they should not be participating in planning poker

[sokoloff]

They shouldn’t be bidding, but participating to answer clarifying questions or discuss tradeoffs seems healthy.