Also, to get better estimates you need to sometimes do some [research] work. Without it ykur guesses are even wilder but with it you have to ack that you've spent time on it, evenif you never get to do the actual work.
Sigh, this was the basis of "Iterative Development" that came along with the "Rational Unified Process" and was the precursor to the current fad of epics/stories/sprints/t-shirts/Fibonacci that has polluted current programming.
People won't follow it because it means reviewing their assumptions and re-planning, but there are always external entities that will not or can not do so (other departments, finance, customers, marketing, sales, etc etc).
As with many development methodologies, it probably has a formal version that I'm not understanding.
But in my head, it's always been (1) identify areas of risk, (2) sprint to a prototype that decreases or quantifies that risk, (3) evaluate whether you've reduced risk sufficiently, then either (4a) proceed to the next risk or (4b) do another prototype sprint on this risk, and finally after all pockets of risk have been reduced (5) begin building your finished product.
Believe it comes from state of the art development for military procurement, where "What is even possible?" is a valid question.
But it always resonated with software planning for me, by making it more about risk reduction rather than guessing.
