How do you financially quantify the 'holding cost' of not releasing items until you have a big batch?

Question

In Don Reinertsen's book - Principles of Product Development Flow - the tradeoff between release size (number of stories) and release cost (regression test cost and release cost) is described like this:

In Ken Rubin's book - Essential Scrum - he talks about the benefits of smaller release sizes - being:

• Reduced cycle time
• Reduced flow variability
• Accelerate feedback
• Lower risk of failure
• Reduced overhead
• Increased motivation and urgency
• Reduced cost and schedule growth

He also uses the following way of describing this tradeoff:

They both talk about this in terms of a U-curve optimisation problem. The challenge is how to quantify this.

Now assume:

The above has the form of

cost = n*BS + m/BS 

with

• n = holding cost factor,
• m = transaction cost factor and
• BS= batch size.

You have to find the zero crossing of the first derivative for the minimum. The first derivative for the above is

n - m/(BS^2)

When setting that to zero you find

min cost = sqrt(m/n)

But how do you find the cost of releasing now vs releasing in six months? What was the opportunity cost?

My question is: How do you financially quantify the 'holding cost' of not releasing items until you have a big batch?

Answer 1

Depending on the type of project we use different approaches, some examples below:

1. If the project is improving internal efficiency, then it's very easy to calculate ROI. The opportunity cost will be then a function of product value and time.

2. If the project is about updating obsolete solutions, we use risk-based approach. The opportunity cost will be then a function of [growing] risk and time.

3. If the project relates to regulations compliance, we typically use a simplified approach, namely we consider the risk of being incompliant to always overweigh the release overhead cost (we work in medical industry, being incompliant there means huge direct and indirect losses) - then we release as soon as the regulation in question comes into force.

4. If the project is related to external customers, then we can involve them in the evaluation exercise, since it's not only our cost / value, but also theirs.

Answer 2

A slightly different approach would be to use Earned Value Management - https://en.wikipedia.org/wiki/Earned_value_management .

While EVM has gone out of style for being unwieldy and hard to define when value is earned (especially in software), you don't have to use every formula and data point. If you and your stakeholders can agree that value is earned when the software is shipped, then you can track the ongoing spend of building software (the Actual Cost) against the Earned Value of released software. That will show the increasing AC against a EV that flatlines until you do a release.

You could also do scenarios of including the effort to perform a release, and comparing the differing release sizes versus when value has been earned.