Cost of Delay (money lost becuase something hasn't been delivered) is a big deal, often > cost of development. It's hard to determine, tho, involving lots of guesswork. Fortunately, in an agile world, we don't need to have to have a hard number. 1/6
We can assume that the more valueable something is to our customer, the higher the relative cost of delay. "Relative" is all we need. In waterfall (and SAFe) shops, you need complex formulae (e.g. WSJF) for CoD because the timeframes are so long & dev time is a factor. E.g 2/6
If you have a small thing with a high CoD, and a large thing with a low one, do the small thing first. The time added to the long thing won't impact its CoD all that much. However, in an agile (SAFe isn't agile) shop, we can make the units of work very short. 3/6
If all stories take a day or two to implement, then that variable (the denominator in WSJF) drops out of the equation entirely, and we arrive at a simple: do the most valuable thing next. Not doing that adds cost. 4/6
I'll add to the above that Reinertsen, who came up with the notion, uses CoD for comparison purpose, but the notion applies even if you're not comparing. E.g., the delays inherent in bureaucratic overhead == lost revenue. 5/6
If you're trying to save money, a good place to start is looking at how to eliminate unnecessary delay. 6/6
Share this Scrolly Tale with your friends.
A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.
