Michal Iwanicki

No, I agree; the complexity has gone up immeasurably. Which is *why* it is so important to scope the schedule as much as possible as early as possible & continuously to reduce complexity. And, again, prioritized backlogs doesn't allow for that, but time-estimation scoping does.

How many engineer-hours does your time think it will take to make the estimates correct? Can you give me an estimate for when your time estimations will be proven correct or not? If they are off, how long will it take to get more correct estimates?

You are arguing against some sort of strawman of your own making. I was very precise when I said "give actual best effort estimates." Nowhere did I say "correct estimates." (It's also why I said "with probability.")

“How long will this take?” Is not a useful question in my experience. Rather “this is how much this is worth” is better. If it ends up taking any longer stop and cut your losses. Start with Plan B first so you have something to cut losses back to. Manage risk and ROI.

Individual estimates are not what are important; the totality is, because that allows you to plan across the whole project where things land (roughly) w.r.t. particular milestones. Now (and only now) can you *show* that terrain-blah won't happen in time, so either replan or cut.

I’m pretty confident we’re not really disagreeing on the general practice @ChristerEricson

I'm pretty sure your suggestion that after-the-fact scoping "is better" isn't compatible with my scope-upfront is the right way stance. I don't see how that would work. After-the-fact scoping is part of why game schedules are hit and miss. I described how to correct that.

I scope by value before-the-fact. There are milestones and deliverables. Plan B is generally low risk and either more reliably estimable or cost-to-discover is low. I am not arguing that you don’t plan deliverables. I’m saying you plan according to their value to meet them.