The irony of a Definition of Ready:
Let's not work on something because we are scared it will take longer, hence guaranteeing with absolute certainty it will be delayed.
When you're not ready, and take the time to make it ready, you're still not ready.
As you do the work you discover everything that must happen, not just what you thought was necessary before starting.
It's not idle developers you should be worried about, but idle work: Cost of Delay kicks in when you delay something with a Definition of Ready.
And if your Cost of Delay consistently is less than the cost of your team, you're not running a sustainable business. That's the problem you should fix, not having a better Definition of Ready.
Delaying work to try and prevent obstacles you cannot prevent is a costly affair.
The sooner we start the work, the sooner we will discover the obstacles that truly matter.
The obstacles that matter are never covered in your Definition of Ready because they cannot be known before doing the work.
The real problem isn’t preventing all the obstacles we can prevent. Its discovering the obstacles we can’t prevent sooner so we can shorten the time-to-market and deliver more value.
Can you elaborate on the "Cost of Delay is lower than the cost of your team" part. I don't understand its meaning.
I'm inclined to say that if CoD > CoT your business is not sustainable