Jim Tilander

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

"By value before-the-fact" is what engineering always typically try to do, but it's a weak method that cannot ever tell you upfront how you're likely to miss something on milestone N, and that you should replan or cut. For $100M+ projects we should do better.

My problem with estimates is that they always, no matter what, are wrong, and pretty much every tasks just stretches out to whatever deadline you choose. What I prefer is to do just that: 1/2

set a deadline, figure out the scope, rate task sizes 1-5, assign people (everyone has estimated bandwidth - say senior can do one '5' task a year), check if no one is over their bandwidth to see if you're going to fit in schedule, track progress of each task along the way 2/2