Cost of Delay
What it costs the business per unit of time that a piece of work is not delivered, which is the input that makes prioritisation an economic decision.
Prioritisation arguments are usually about value, which produces a queue ordered by advocacy. Cost of delay reframes the question as economics, and the estimation exercise itself is more valuable than the number.
It combines: business value — revenue gained or lost; time criticality — whether the value decays, and whether there is a deadline or a market window; and risk reduction or opportunity enabled.
Divided by job size it produces weighted shortest job first, which maximises value delivered per unit of time for a queue of independent items.
Why it works organisationally: asking "what does it cost us not to have this for another quarter" forces a conversation the organisation avoids. Many items turn out to have a cost of delay near zero, which settles their priority without further debate and frees the argument for the ones that matter.
For architecture and platform work specifically, this is the framing that lets enabling work compete with features rather than being classified as "technical" and deferred: enabling work has a compounding cost of delay — every quarter without it, everything downstream is slower.
The cautions: it assumes items are independent, so dependencies are resolved first; and estimates are judgements, so use it to produce relative ordering and surface disagreement rather than a precise ranking to be defended.