RoI - the word alone is a Litmus test. If you know it, you know it. If you don't, you've immediately disqualified yourself from the business world. Or is it not that simple after all and no reason to get angry now (pH-low, because that's what the litmus test actually tests)?
RoI - the supposed classic
The return on investment (RoI) describes the minimum form of bartering: I give something (investment) and get something in return (return). A still acceptable barter trade earns me as much as I give (return/investment = 1), a good one always earns more (return/investment ≥ 1). If my RoI is negative, then I do not enter into the trade. And if I do, it's out of stupidity. Right?
What is often forgotten in discussions about ROI: It is a bet on the future. Because I have to make an investment first and a return can be a long time coming. And this is where the first difficulty with RoI lies. Without a time reference, it is not meaningful. In finance, for example, a RoI YoY (the last 12 months, also known as yearly trailing RoI) or a RoI 3y (RoI over three years) is therefore specified. Even then, the basis is still important, the reporting date. It makes a difference whether I use March 1, 2020 or October 1, 2020 as the basis. In the financial sector, the balance sheet date is obvious.
In the operational corporate context, the RoI is not suitable for many decisions because both the dates of the valuation and the periods under consideration usually do not match. How meaningful is an RoI of 1.13 from 11.02.2022 compared to an RoI of 1.21 from 14.11.2021?
Why is the RoI still used?
And yet RoI is widespread. Unfortunately, even in the "agile world". Even if it is not called that. Backlog items are evaluated according to effort and benefit, and sometimes even the quotient of the two is calculated. That is then the RoI!
It's just silly when one estimate is three months old and the other is from yesterday, one refers to a period of four months and the other to two years. Especially if the estimates are made over a longer period of time as part of rolling planning and emergent backlogs. It should have dawned on everyone by now at the latest: This doesn't fit backwards and forwards.
But there is another problem: not all effort is the same. There are activities that take ten minutes, then you have to wait three weeks, then work on them for another five minutes. Is the effort now minimal at 15 minutes or greater than many a sprint at over three weeks? And shouldn't it then be split up so that it fits into a sprint? How would that work?
I can already hear the agile preachers taking a breath for the ONE sentence: "But we estimate effort relatively, according to complexity". Excuse me, what is this "complexity"? Three people probably have three ideas about it.
But back to the topic. If effort and duration differ greatly, this has a negative impact on the meaningfulness of the RoI. And let's be honest: a large part of the time in development consists of waiting.
So why is RoI still so widespread?
It is the simplest comparison of cost and benefit. It would only be simpler to look at effort or benefit. And it's obvious: the effort is assessed by the developers, the benefit by the customers. But are they really the kings of this decision? You can read my clear no here. What idea do they have of the internal synergies I create with a decision? Taken one step further, this argument reveals that even within a company there is rarely one expert for all facets of an entrepreneurial decision. Incidentally, one person is not an organized company, so a single person does not count.
Work is always prioritized. But how would it be good?
In the last article, I argued that it is not possible not to order. So if you always prioritize, but unfortunately the RoI is no good, how do you proceed?
All the nagging against ROI is not getting us anywhere. We need an alternative that reflects the economic framework in companies.
Fortunately, there is a more suitable economic approach
In fact, there are quite a few studies on the decision parameters that shape companies. With a view to product development, I will pick out a model that offers many points of reference. Donald (Don) Reinertsen describes in the book "The Principles of Product Development Flow" that every entrepreneurial decision must be economic. In his own words, quoted from his book:
While you may ignore economics, it won't ignore you.
Don Reinertsen
Incidentally, I toured with Don a few years ago for a week full of insights, I have described my experiences here. His approach is based on a minimum number of variables that are interconnected. These can be quantified, but only in combination. Almost every decision is a trade-off, some more, some less. In econometrics, there are a whole range of analyses on this, known as sensitivity analyses. For us, however, it is simpler. All the variables we need can be found in the following image:
From the interaction of
- Cycle time (the implementation time, not to be confused with the lead time, the completion time including waiting times),
- Product cost (costs directly attributable to the product),
- Development expense (costs indirectly attributable to development),
- the product value (in the simplest variant price, but often characterized by more sub-variables)
- and the direct and indirect risk that is always subject to
a variable can be aggregated that takes into account all factors of an economic, i.e. entrepreneurial, decision in product development. This variable is called Cost of Delay.
Cost of delay as the leading key figure
The Cost of Delay (CoD) quantifies the costs of the queue. This means that all ideas waiting to be developed can be evaluated at any point in time. Hence the cost of delay. The aim is to keep these costs as low as possible. Of course, the CoD is not the only variable for entrepreneurial decisions in product development, but it should be the first:
If you only quantify one thing, quantify the cost of delay.
Don Reinertsen
Strictly speaking, every prioritization decision is a sequencing decision: the order of the topics to be processed is determined. This influences the value of the planned topics (upstream) on the one hand and the value of the topics being implemented (downstream) on the other. And whenever something very urgent needs to be implemented very quickly, the value of the queue changes. An example can illustrate this better than many words:
Three features (A, B, C) are to be implemented - see the table on the right-hand side of the image.
It is tempting to start with C (gray field at the bottom left). After all, it takes the longest, so it's better to start earlier. Unfortunately, this has an effect on A and B. While C is being implemented, these two will incur delay costs of 160 units.
So it's better to start with A, as shown in the partial image above left, then continue with B and finally work on C. It takes the same amount of time overall, but the delay costs are over 20 times lower at seven units!
And while A and B are being implemented, someone may even have an idea of how C can be divided into smaller units.
We've already come this far, but the question remains: How can I use it now? That's why I'm introducing WSJF.
WSJF - Weighted Shortest Job First - Wait what?
Weighted Shortest Job First (WSJF) is unfortunately not as easy to understand as RoI the first, second and eighth time around. Nevertheless, it is much more important. I'll explain why now.
The units of planning (e.g. backlog items) in development/companies are usually neither the same size nor the same value. And this is exactly when the WSJF is needed.
If the effort is the same, but the value is different, then I can order according to the delay costs, i.e. "Highest Cost of Delay First".
If the value is the same, but the effort is different, then I can implement according to the shortest effort (cycle time), i.e. complete what is quickest first ("shortest job first"). Sure, that way I get my value delivered earlier. In simple terms: duration is only measured by the implementation time.
After all, this is the decisive factor when I consider whether to implement one or the other alternative. However, if the cycle time is essentially determined by waiting time, as in the picture for example - because I have to wait for an expert - then it loses its significance. In practice, firstly, this cannot always be determined in advance and, secondly, it is not decisive in the context of the usual estimation inaccuracies.
Determining the WSJF means making entrepreneurial decisions
The WSJF is therefore made up of cost of delay and cycle time (job duration).
© Scaled Agile, Inc.
The cost of delay can be derived company-specifically from the economic framework shown above. The Scaled Agile Framework (SAFe) proposes a generic formula for simplification:
© Scaled Agile, Inc.
In some companies, weight (e.g. SpaceX, the aerospace company) or safety (e.g. Areva, the nuclear reactor manufacturer) can also form a variable for the cost of delay. Furthermore, individual factors can be weighted higher, for example "Risk Reduction and/or Opportunity Enablement" for a bank. However, before building complex formulas, I recommend simply starting with the formula recommended by SAFe.
Importance of job size as a lever for prioritization
This WSJF formula à la SAFe also reveals the biggest lever: Job Duration. In the example below, A is more urgent, as well as more significant for "Opportunity Enablement and/or Risk Reduction". Nevertheless, the calculation shows that A should only be tackled third because the WSJF calculation shows the lowest value. How can this be changed?
© Scaled Agile, Inc.
Option one is of course to "turn up" the business value of A or "turn down" that of B and C. Don't trust any statistics/calculations that you haven't falsified yourself...
In the agile sense, however, there is a better lever: Reduce the job size! Even reducing it to a value of 13 makes A the first choice (WSJF=3.3). So the consideration should always be: How can I achieve a similar goal (CoD) with less effort?
If that's not agile, entrepreneurial and just plain smart!
But...
...WSJF also has weaknesses. As with RoI, the timing of the estimate is always important with the WSJF. In contrast to RoI, the WSJF does not allow any consideration of time periods - although forecasts remain a bet anyway.
And now you!
What are your experiences with the WSJF?
What would you like to know about this? We could start an online meeting on the topic, what do you think?
Write a comment