Ranking work, whether it's for the backlog, a roadmap, or the portfolio, sometimes feels like throwing darts and hoping for the best. But especially if there's too much work and a lot of WIP, we have a tool for clarifying that ranking—the Cost of Delay. It does require counting the number of people and easy multiplications.
This post is about how to calculate and compare various Costs of Delay. (See the entire series at the end of this post.)
The first two posts help us see the questions and the first two possible Costs.
- Part 1 is about seeing the various costs and asking if the work is still valuable: Should we do this work at all? In addition, Part 1 discussed Cost 1, the salaries when the people have not yet released the work.
- Part 2 explains how to calculate Cost 1 and Cost 2. Cost 2 is the effect of lost sales for the time you have not yet released the feature or the product.
This is the picture of the various costs.
Now, we have a chance to decide what's most valuable.
Determine the Most Valuable Work
The most valuable work gives you revenue or the equivalent (adoption, enablement) faster. Sometimes, that work is internal work that does not immediately provide customer value, such as that build system I wrote about in Part 2.
For every project under consideration:
- Ask the zeroth question to make sure the work still has value. If the work is no longer valuable, don't consider it any longer.
- Write down the weekly salary cost of everyone you need to pay to release product. That's Cost 1.
- Write down the number of features remaining until you can release.
- Write down your cycle time per feature. (See How to Move from Story Points and Magical Thinking to Cycle Time for Decisions.) If you've been multitasking forever and have no idea what your cycle time is, use the order or magnitude guess that the team generated in Part 1.
- Cost 2 is the time you need to finish enough features (either cycle time/feature or order of magnitude) times the salary costs to finish.
We clearly need an example.
An Anonymized Example of Cost of Delay for Ranking
I'm using projects in this example, because ranking projects often offers the most value for reducing WIP and focusing the organization. (See Flow Metrics and Why They Matter to Teams and Managers.) This is a real example from a client with too many projects and too many people multitasking:
If you look at just the weekly cost for the necessary people, you might think that Project C is the clear winner. Especially if you then see it only needs one feature to release something. But that cycle time of three weeks—that's suspiciously long. However, the expected weekly revenue—that's suspiciously high.
When I see a cycle time of three weeks/feature, I'm pretty sure the team has no idea how long things take. In this case, the “team” so rarely worked together they had no idea how long things took. Worse, I was pretty sure the expected weekly revenue was pulled out of someone's hat. I asked questions, and yes, that revenue was pulled from a hat. However, the potential revenue might have been much larger than the other three projects.
I needed to ask more questions.
Ask More Questions
Since I had many suspicions, I asked the team for Project C to say how long that one feature would take. (That was the anonymous question in Part 1 of this series.) Because Little's Law always wins. (So does Murphy, etc.) I also asked if the team needed more people to finish and release. Yes, they did.
Project C needed 8 people. That changed Weekly Cost 1 to $16,000. And the Cost to Release was now $16,000 * 3 = $48,000. Even if the expected Weekly revenue was only $250,000, we could see that revenue with just $48,000 and three weeks of time investment.
Our next possible winner is Project D. If they know their cycle time is roughly three days and they only have two features to complete, their cost of $28,800 looks quite good compared to the other projects. We could start to see revenue much faster (in less than half the time of Project C.)
Because the company needed revenue fast, and I didn't trust the Project C predictions, I recommended the company finish Project D, and then move everyone to Project C.
Project D is a great example of WSJF: Weighted Shortest Job First. In general, I'm not fond of WSJF for quarterly-based portfolio decisions. Too often, we learn that WSJF is not short enough. However, if we need to ship something now or if we want to rank a short-term backlog, WSJF can work. It all depends on how normal the cycle time is. (See How to Move from Story Points and Magical Thinking to Cycle Time for Decisions for how to think about cycle time and predictions.)
But WSJF is often related to cost, not value.
Discuss the Value of the Work, Not the Cost
I always rank by value. Always. Never by time or cost, because we can't depend on predictions for time or cost. And long cycle times make me nervous. Too often, teams don't know their cycle time.
If we can depend on or trust these numbers, I would rank the work like this:
- Project C, because the return is so high. That is a little risky because the cycle time is three weeks/feature. That's long. However, the value of that work is much higher than the other three projects. Notice that team-based trust is a huge piece of this decision. This is how you're supposed to use Cost of Delay. Start and finish the most valuable work.
- Project D, because, for a small investment, we get a useful return, right away. And we can decide to limit the time for this work to not more than two weeks.
- Project A next, because while the return is lower than Project B, the cycle time is also much lower. That's a risk-averse approach.
- Finally, Project B, again because the cycle time is quite high.
You might choose a different ranking, but not because you believe something about the projects. Instead, you have different data, so you might not be as risk averse as I am. If you can trust the teams to deliver when they say they can, you might even rank Project B ahead of Project A because the expected revenue is much higher.
This is why teams need to build trust across the organization with a more dependable cycle time.
You also have another options: Reduce the total number of projects (reduce WIP) and put everyone on just one or two projects. Then, use the ideas in pairing, swarming, and mobbing so the team collaborates on all the work.
Now that you know the calculations, I'll summarize in a final post.