Delphi Method
en.wikipedia.org
en.wikipedia.org
When one person on the team says an element will take one week and another says 8 weeks, there are fundamental differences in assumptions that need to be worked out. That was the good part of the process. The bad was when the Project Manager doesn't let the process play out and simply takes the shortest of the available estimates.
https://en.m.wikipedia.org/wiki/Wideband_delphi
Edit: as I recall from doing estimating using wideband Delphi circa 2004, the main differences with planning poker as I see it practiced today are that estimates were in real time like days or weeks, and votes were collected and displayed anonymously, though as you would expect there was temptation for people to de-anonymize their own votes.
Waterfall failed for many reasons, but one of them was because you’d get asshole project managers constantly taking minimal estimates exactly as you describe and then applying pressure on individual devs when they overrun the minimum estimates.
One of the biggest contributors to developer happiness and productivity over the last 20 years has been to escape this tyranny.
Kids today conflate "throw it over the wall" with waterfall.
Agile rejects planning, foresight, vision, end goals. Agile was explicitly concocted to manage upwards, in those organizations unable or unwilling to do proper planning. Unfortunately, the originators wrote down their survival tips, which were then misunderstood by noobs and embraced by profiteers. Just like every other religious text.
Agile is not the victory of iteration over some imagined dark ages of project chaos. The Agile Methodology is to argue about the Agile Methodology. The cult(ural) spread of Agile is no different than any other vacuous self-help omni-fix content-free dogma.
Because project management is not a critical success factor.
Most projects are late, buggy, or outright failures.
One response was to improve project management. That worked okay. But like with most knowledge work, requires some effort.
Another response was to accept the failure rate and simply throw more resources at the problem.
aka Worse is better.
That's the genius of the Agile Methodology. Per the Zeroth Law of True Agility [0], we're both utterly correct. With no contradiction.
[0] The Agile Methodology is to argue about the Agile Methodology.
For some people and organizations, the purpose of estimates is not primarily informational.
Sure nice it doesn't work on competent developers, not with the current job market.
We've only replaced the tyranny of deadline crunch with the tyranny of daily micromanagement. You can't even wipe your own ass without so much as a Jira ticket and half a dozen people signing off on it.
And despite all of the rigmarole and rituals, you still have deadlines. Doesn't matter what the Jira board says. If some upper management dickweasel wants their feature, they will get it. Forget the story points and estimates.
It doesn't make it worthless, though. If you had a 20 person company where ownership was legitimately interested in getting the best answer to the problem, maybe this is an efficient way of doing that.
Perhaps the most valuable part is the discussion after making that second forecast. We identify a lot of bias and assumptions people were making that they then learn from the next time they have to make a forecast like that.
EDIT: Looking more into it, it seems that it went from "Delph method" to "Wideband delphi" to "Planning poker", and it's in the last step that the anonymity requirement disappeared. Very interesting!
Although I have not used it in practice yet, I like the concept, especially for some more difficult (bigger) estimation tasks, so I am mentioning it in my book besides other "group estimation techniques".
It is true that this is basically async "planning poker".
A Jamboard delphi session perhaps.
(Also: Roni, the head of this research group, was my PhD thesis advisor more than ten years ago!)