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

I get that. But as a tech guy I sometimes get itchy when the actual reality of things is ignored. A good example would be when a customer demands something that is mathematically or physically not possible. With wishes like these you could the do the planning poker all day and maybe land at a compromise that is still not possible.

As a former freelancer I am a big fan of just getting a thorough explaination of the problem, maybe with me looking over the shoulder of someone who has to solve it currently. And then I vanish in a hole for a few days and return with the design proposal I think would most elegantly, reliably etc solve the problem.

Unless we are speaking about people who have good experience with complex problems, most people are okay at describing their problems, but suck at proposing solutions (they are always modelled after the limited things they know).

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

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

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

Always a good time to rewatch the expert: https://youtu.be/BKorP55Aqvg?si=eqw2-mWA1T3FDUtl

> most people are okay at describing their problems, but suck at proposing solutions

Yes, it's best to focus on their problems and the consequences of proposed solutions. They shouldn't care about your caching strategy internals but they do care about whether stale info impacts their users or what scale it's reasonable to hit, or how much extra it'll cost to implement.

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.

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.

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

> I've definitely seen devs assume too much needs to be done

Absolutely this, and managers and pseudo-managers like product owners, business analysts and full-time scrum masters do too. I see a lot of weird requirements, often technical in nature, that nobody actually asked for, it was just a long string of people who just assumed. Like an infinitely scalable microservice architecture with a full SPA just to let a dozen internal users download some data as an Excel spreadsheet.