The problem with acceptable bounds is when they're applied uniformly to all your code monkeys without adjusting for experience and mental state at any point in time and we can't sample those values in real-time.
Performance metrics are often too noisy to be useful so proper bounds are too difficult to set without the "experience" of seeing the team work over a very long period of time.
Predicting the future of a high entropy system is predicted to always be hard if you're aiming for 99% accuracy. Solving for hard problems AND solving for this particularly hard problem on a daily basis is less energy efficient than if you stop trying to predict the future at every standup and trust that your average best guess while ignoring the future is good enough to keep you going until the end of this task.
TL;DR: Spend less energy sampling the efficiency of human creativity and spend more (but still not too much) on removing barriers that limit creativity.
What pop nonsense. An unpredictable software engineering team is itself a barrier limiting the creativity of the product team (and vice versa). If you don't want to be treated a crank to turn, you also need to bring some self-reflection, compromise, and willingness to communicate to the table.
Picking the 99% or top decile or whatever is not padding, it's the actual job of estimating. Anyone who talks about "padding" rather than uncertainty doesn't understand estimating yet.
A product team without an engineering process can reliably do nothing (but not vice versa). If you don't want to be treated like an optimization that only makes sense in a large money-printing machine, you need to stop optimizing for money-printing.
Communication isn't just about gracefully accepting expected input and feeling good about getting it. It's also about reliably figuring out the logic behind unexpected input to gracefully bridge the gap.
So hacking means creatively staring at unpredictable systems until they make sense. You can timebox how long you can afford to stare at it and then incrementally review whether your staring method should be improved or whether it makes more sense to do something else after the timebox but you shouldn't poll the state of the world every day.
TL;DR: Stop opening the oven door every 5 minutes, you're losing heat every time. Muffins don't like that.
Performance metrics are often too noisy to be useful so proper bounds are too difficult to set without the "experience" of seeing the team work over a very long period of time.
Predicting the future of a high entropy system is predicted to always be hard if you're aiming for 99% accuracy. Solving for hard problems AND solving for this particularly hard problem on a daily basis is less energy efficient than if you stop trying to predict the future at every standup and trust that your average best guess while ignoring the future is good enough to keep you going until the end of this task.
TL;DR: Spend less energy sampling the efficiency of human creativity and spend more (but still not too much) on removing barriers that limit creativity.