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