The problem is, unless you’re talking about work that can fit into the next 3 days (often, even then), it’s notoriously, outrageously hard to estimate engineering time, so estimates are frequently wrong by as much as several orders of magnitude.
Look into the building of the Sydney Opera House for a famous historical example.
We never build software that has been built before. We don’t have applicable prior experience to draw on, and without that applicable prior experience, it’s impossible to properly estimate how long it will take.
In other words, all software estimates are worthless lies. Dealing in a fantasy is worse than having no deadline, because people do things like make sales and marketing promises to customers based on your worthless lie of a deadline, and then you have customers mad at you when you miss it.
There are countless historical examples of exactly that happening. (Google vaporware).
I’m not saying don’t commit to getting work done. That’s why I emphasized the importance of breaking work up into smaller stepping stone MVPs.
You should be shipping useful stuff to production constantly. You should demo new work about once per week to keep stakeholders appraised of progress.
In that situation, scope creep is not a problem. In fact, it’s easier to avoid scope creep because stakeholders know exactly what is being prioritized and built at all times.
Deciding on priorities for the MVP and what to build next is a constant, iterative process with lots of openness and transparency.
I’m not telling you to throw away accountability. I’m telling you to deal in reality, and be accountable only to true, realistic measures, and not to somebody’s delusional fantasy about when something should be done.
When you operate on the “ship early, ship often” philosophy, you’re held accountable for progress frequently, and you’re always dealing with the truth about what’s been done and what the real priorities are.
Don’t toss away productivity expectations. Do keep them grounded in reality.