I have the software engineering uncertainty principle. The more you try to measure and estimate and predict software velocity and delivery the more you slow it down. I think this is probably true of any largely creative and problem solving task, but compounds because most of the uncertainty derives from dependencies requiring those dependencies to likewise measure and slow down. The more complex and interconnected an effort is the more scrum hurts it.
This sounds a lot like the coastline paradox. The more precisely you try to measure a coastline, the harder it gets due to its fractal nature.
Software estimation, similarly, is fractal in nature - you can always drill down deeper to measure but it gets increasingly complex and at some point you have to ask, is it worth it being "accurate"? Or do we just do it? Org charts require the former while developers desire the latter.
I think that analogy is broken. Measuring a coastline more precisely doesn't just become more complex (measuring precisely often does), but actually increases the measured length towards infinity.
Unless you wanted to say that the same is true for software estimation, e.g. due to the measurements taking up more and more time.
Yes, I meant the time taken estimating. The act of measuring estimated hours becomes more complex because the closer you look, the more you see, you could do it forever and have to stop somewhere.
But maybe instead of infinity, it's better to say estimation can take longer than the work itself which has been the case a few times for me.
