Over a million developers have joined DZone.

Continuous Delivery and Cost of Delay

DZone's Guide to

Continuous Delivery and Cost of Delay

· DevOps Zone ·
Free Resource

Do you need to strengthen the security of the mobile apps you build? Discover more than 50 secure mobile development coding practices to make your apps more secure.

Use cost of delay to value continuous delivery features.

When building a continuous delivery pipeline, we want to value and prioritize our backlog of planned features to maximize our return on investment. The time-honored, ineffective IT approach of valuation by intuition and prioritization by cost is particularly ill-suited to continuous delivery, due to its focus on one-off infrastructure improvements to enable product flow. How can we value and prioritize our backlog of planned pipeline features to maximize economic benefits?

To value our backlog, we can calculate the cost of delay of each feature – its economic value over a period of time if it was immediately available. Described by Don Reinertsen as “the golden key that unlocks many doors“, cost of delay can be calculated by quantifying the value of change or the cost of the status quo via the following economic benefit types:

  • Increase Revenue – improve profit margin
  • Protect Revenue – sustain profit margin
  • Reduce Costs – reduce costs currently incurred
  • Avoid Costs – reduce costs potentially incurred

Cost of delay allows us to quantify the opportunity cost between a feature being available now or later, and using money as the unit of measurement transforms stakeholder conversations from cost-cutting to delivering value. Calculation accuracy is less important than the process of collaborative information discovery, with assumptions and probabilities preferably co-owned by stakeholders and published via information radiator.

Cost of delay = economic value over time if immediately available

To prioritize our backlog, we can use cost of delay divided by duration (CD3), a variant of the weighted shortest job first scheduling policy. With CD3, we divide cost of delay by duration, with a higher score resulting in a higher priority. This is an effective scheduling policy, since the duration denominator promotes batch size reduction.

CD3 = cost of delay / duration

Since the goal of continuous delivery is to decrease cycle time by reducing the transaction cost of releasing software, a pipeline feature will likely yield an avoid-cost or reduce-cost benefit intrinsically linked to release cadence. We can therefore calculate the cost of delay as one of the below:

  1. Reduce cost: automate action(s) to decrease wait times within release processing time

    = (wait time in minutes / cycle time in days) * minute price in £

  2. Avoid cost: automate action(s) to decrease probability of repeating release processing time due to rework

    = (processing time in minutes / cycle time in days) * minute price in £ * % cost probability per year

For example, consider an organization building a continuous delivery pipeline to support its apples, bananas, and oranges applications by fully automating its release scripts. The rate of business change is variable, with an apples cycle time of one month, a bananas cycle time of two months, and an oranges cycle time of three months. Our pipeline has already fully automated the deploy, stop, and start actions for our apples and bananas applications, but lacks support for our oranges application, our test framework, and our database migrator.
Application Estate Once our development team have provided their cost estimates, how do we determine which feature to implement next without resorting to intuition?

Backlog Duration

We begin by agreeing with our pipeline stakeholders an arbitrary price for a minute of our time of £10,000, and calculate the Cost of Delay for supporting the Oranges application as:
Support Oranges application

= (wait time / cycle time) * minute price
= (20 + 20 + 20 / 90) * 10000
= 0.67 * 10000
= £6,700 per day

Given that the test framework has failed twice in the past year and caused a repeat of release processing time specifically due to its lack of pipeline support, the cost of delay is:
Support test framework

= (100 / months in a year) * occurrences
= (100 / 12) * 2
= 16% cost probability per year

= (processing time / cycle time) * minute price * % cost probability
= ((100 / 30) + (100 / 60) + (160 / 90)) * 10000 * 16%
= 6.78 * 10000 * 16%
= £10,848 per day (£5,328 apples, £2,672 bananas, £2,848 oranges)

The cost of delay for supporting the database migrator is:

Support database migrator

= (wait time / cycle time) * minute price
= ((45 / 30) + (45 / 60) + (45 / 90)) * 10,000
= 2.75 * 10000
= £27,500 per day (£15,000 apples, £75,00 bananas, £5,000 oranges)

Now that we have established the value of the planned pipeline features, we can use CD3 to produce an optimal work queue. CD3 confirms that support for the database migrator is our most urgent priority:

Backlog CD3

This example shows that using cost of delay and CD3 within continuous delivery validates Mary Poppendieck’s argument that “basing development decisions on economic models helps the development team make good tradeoff decisions". As well as the fact that learning support for the database migrator is twice as valuable as any current alternative, we can offer new options to our pipeline stakeholders - for example, if an apples-specific database migrator required only 5 days, it would become our most desirable feature (£15,000 per day / 5 days = CD3 score of 3,000).

Check out tips for blazing the way from agile to DevSecOps with security built into your mobile app toolchain.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}