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

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