You could say "requirements are satisfied", is the threshold but those always change on a project. You need to predict what you need in the future. No one is good at that, but the fact that some may be lucky does not imply that it's possible. Doing it right in a schedule based environment means contract renegotiation. This could be expensive and many times its easier for the customer to bypass management and convince the engineers to take on more scope for free. This happens all the time, project managers need to be vigilant! But vigilance does not build value, it just creates avenues for conflict.

Regardless of what your methodology is, every successful project will become a "unknown deadline, flexible features" product at some point in its life-cycle. Why are we bifurcating that stage at an arbitrary point based on faulty assumptions made months and years in the past? What agile does is it moves the arbitrary bifurcation point to t=0 and avoids classes of zero-sum customer-management-worker conflicts.

I'm unconvinced. If new features of unknown complexity are getting added to your product backlog with the expectation that estimations are done against them and not that exploratory work is planned and undertaken instead, that's a problem with the culture and not with the process.

Scrum in particular (according to Coplien et al. at least) is meant to handle prioritization of work as a conversation between the people who want stuff built and the people actually doing the work to get stuff built. The only thing it recommends—not even prescribes—as it relates to estimation uncertainty is embracing the framework to chart a new course more easily when the facts change.

A big pattern that is prescribed (though perhaps only implicitly via reiterating that the product backlog is strictly in delivery order when work starts) is that the product backlog is append-only when you don't want to trigger more planning and, as a direct consequence, draw up a new refined product backlog for everyone to work from. If you need to reorder your product backlog items to add something in the middle, that's a signal that the facts have changed, and the plan needs to be redone. That isn't prima facie all that different from a more traditional project management method.

Agile only aims to make planning suck a little less to change by baking certain touch-points into the process so that someone can pull the proverbial andon cord unceremoniously.

> Agile is better suited for exploration of a product space

More apropos this, if you've ever heard of a spike solution, that's agile's attempt at controlling for uncertainty when it isn't exactly clear how to do something or how long something will take. It necessarily triggers additional planning, and the product backlog item for it is a clear display of the uncertainty inherent in delivering that helps determine where in the ordering that work should fall.

Likewise, if you generally know what the roadmap looks like and have confidence that it won't change, the uncertainty is still in the humans doing the work. I've always put vacations and bereavements and on call shifts and other kinds of fixed-date "generally not available for product work" things into the product backlog, and having that visible to everyone with stake in the work is always valuable.