"No, it's less effort than that"

A valuable discussion to have is about how to change the scope so that the cost/return tradeoff is right for your stakeholders.

I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day.

> There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.

I'm sure people will have flashbacks when I say this so sorry to those, but this is the issue addressed with planning poker. The idea being that you all say how hard the task is, without being affected by each other, and discuss when expectations aren't aligned. Someone is probably missing something.

I might think something is simple because I've not realised a complex part of the problem, or because I can see a nicer neater solution.

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

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.

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