If you are not moving at the speed of the marketplace you’re already dead – you just haven’t stopped breathing yet. ~ Jack Welsh
We are prioritizing in a world where time is precious and resources are scarce. Economics is all about scarcity. We can turn to economics to help us quickly discover, nurture and speed up the delivery of value.[1]
Cost of Delay
A model to examine the cost to the business if a particular feature is delayed.
Unless you are in a continuous deployment delivery model, a single feature rarely goes live. Features are clubbed and though they can be developed independently, the deployment cadence is generally between 1-3 months. For such projects, from a pure business value perspective, all features that would get deployed together would fetch business value at the same time – when they get deployed.
So when there are multiple features part of one release, how do you prioritize them? How do you make the decision that one should be developed before the other? More often than not, it’s a function of intuition and local cost and/or resource optimization.
Cost of Delay in this case should be the cost that a particular feature would incur based on when its developed in the release. It is not just about the timing or the absolute cost of developing the feature as we would further discuss in the article. Now some would argue, each feature is supposed to be independent anyways. In the real world, especially in the world of complex enterprise systems that integrate with hundreds of other systems, that’s rarely the case. So we need a model, a good one to represent this complexity and make some sense out of it for our decision making. Let’s start with a simple illustration.
A simple illustration
As we see from the illustration, doing Feature B earlier might have helped to reduce or even eliminate the delay. Now this is a simple example. For our real world where there are far more variables in play, a more scientific and structured model to arrive at this kind of prioritization is needed
Cost of Delay provides a framework to do this in a structured way. Lets look at the components that make this.
Cost of Delay components
There are essentially three parameters that can lead us to discovering cost of delay. They are business value, timing impact and risk reduction ability. We would want to rate these for each feature on a scale of our choice (I prefer something like 1,2,3,5,8,13,20. You could very well use a Fibonacci series or any other scale of your choice. It does not matter, so far as it makes sense to your context and is consistent. Asking specific, contextual and relevant questions can help us rate each feature on the scale much better.
Business Value
This essentially measures from business terms how better it is to have this feature ready early. A good question to ask here could be – if the feature is ready early, can it be deployed independently and generate some business value? Will a demo of this feature to internal management and/or the customer management inspire confidence and give them assurance that things are proceeding on right track? On our scale we would rate 1 being the lowest value gained and 20 being the highest.
Timing impact
This is mainly to discover if the feature needs to be developed early (because it has other dependent features on it) or has specific milestones / dependencies that impact the timing of its development. The more independent a feature lower score it gets and the more urgent one gets a higher score. e.g A Feature needs to be done earlier to meet a specific milestone of partial delivery to another vendor (to facilitate early integration testing) should get a higher score compared to another that does not need this.
Risk reduction
This is an attempt to quantify the amount of risk that can be eliminated or reduced by getting done with this feature early. Risk could originate from several factors like availability of specialized resources, complex integration and so on. Items that provide the lowest risk reduction are rated lower compared to the items that provide higher risk reduction because of completing them early.
For our example, assuming business value and timing impact are the same (for simplification), risk reduction is rated higher for Feature B because it has some 3rd party integration.
Looking at above table, it seems logical to do Feature B earlier as it indicates a higher cost of delay. However, this is not yet robust in itself, because it does not give any consideration to the size or duration of the features which are important aspects to account for. Let us take look at two such models that take into account these aspects.
Two models to prioritize
Cost of Delay Divided By Duration (CD3) – Based on Duration
The higher the CD3 score, the higher the priority. For more details on CD3, please refer here
Weighted Shortest Job First – Based on Size
The higher the WSJF score, the higher the priority. For more details on WSJF, please refer here.
For our example, if both the features were of similar size, Feature B should be prioritized first.
However if it was the case that Feature A was much smaller compared to Feature B, it would be more logical as per the WSJF score, to prioritize Feature A.
Cost of delay provides a structured economic model based approach to decision making. It makes the trade-offs visible to all stakeholders. It is not perfect and the execution will still throws those wild surprises. Its a tool to help us choose with more awareness of the underlying facts whatever are known until that point. And it does help to change the focus purely from efficiency and cost to speed and value.
Additional references:
http://scaledagileframework.com/wsjf/
http://blackswanfarming.com/cost-of-delay/
http://toolsforagile.com/blog/archives/647/incorporating-cost-of-delay-in-feature-prioritization