In life, sometimes it just seems easier to continue doing things the way we are used to instead of seeking new approaches that may cause the inevitable friction associated with change. This is certainly the case with adopting the Weighted Shortest Job First approach to project prioritization. First come, first serve, right?...
Well not really. Considering the economic impact of delaying one project to complete another first just makes sense. Here's what Weighted Shortest Job First is, and why you should consider using this (and other metrics) when deciding which projects or features get moved to the front of the queue.
WSJF is a method for prioritizing work or projects. It is essentially a method for calculating when it is better to go after the low-hanging fruit vs. the projects that have higher-value, but also cost more to complete.
The idea is that the projects that are of higher value but shorter delivery time, should take priority over projects that take longer and deliver less value.
It starts with assigning a value (or weight) to each project and evaluating how that value changes when the project is delayed. Then we divide the change in value over time, by the length of the job.
But how do you determine value for hardware development projects? Profit? Customer value? Brand impact?
Certainly, profit is the easiest value metric to calculate objectively, but other metrics can also work.
Donald Reinertsen suggests using the cost of delay divided by project duration for hardware product development projects. Regardless of how you calculate value, the fundamental premise remains the same.
Let's use Reinertsen's approach for the purposes of demonstration and providing an example of why WSJF works.
Interested in understanding more Lean-Agile Principles? Check out our free Lean-Agile training on Playbook Academy such as Rolling-Wave Planning, Applying Agile to Hardware and Critical Chain Project Management.
You can read extensively about the cost of delay in our series of posts here. However, for the purpose of this discussion, calculating the cost of delay looks like this.
In order to calculate the cost of delay, we need to understand the behavior of the product life-cycle, and the impact of launching late, on total profit.
Once we understand the cost (impact on profit) of delaying a project launch, and estimated project duration, we can look at what projects, or even features make sense to complete, in what order.
Here are some examples:
Project 1 has a Cost of Delay of $10,000 per month and a duration of 3 months.
Project 2 has a Cost of Delay of $100,000 per month and a duration of 1 year.
Project 3 has a Cost of Delay of $300,000 per month and a duration of 2 years.
Which project should move to the front of the queue?
According to our formula, Project 3 has the highest WSJF score and therefore, Project 3 should be completed first.
Consider the options:
1) Do Project 1 first and delay 2 & 3 for 3 months. Total Cost of Delay = $9.6 M
2) Do Project 2 first. Delay 1 & 3 for 12 months. Total Cost of Delay = $10.95 M
3) Do Project 3 first. Delay 1 & 2 for 24 months. Total Cost of Delay = $3.87 M
So the first decision is clear – to lose the least (make the most) do Project 3 first (the one with the highest WSJF score).
Making the wrong decision can cost millions. Which one comes second though? Compare Project 1 & Project 2:
A) Do Project 2 next and Project 1 last.
Total Cost of Delay = $0.15 M (15 months * 10K/mo for Project 3)
B) Do Project 1 next and Project 2 last.
So Project 2 (the one with the 2nd highest WSJF score) comes second. Again, the wrong decision can cost a lot. When you look at it this way, WSJF just makes sense. You lose less (make more) by doing these in the order of their WSJF scores.
Even though WSJF just make sense, it’s difficult for organizations to ignore the commonly used--first job in the queue gets completed first--approach. But if we take time to look at the numbers, it’s easy to see that we could make a lot more money by doing projects in the ‘best’ order.
Assigning value (here we have used the cost of delay calculation) will vary by organization, but it's worth the effort to answer the question, what does value mean for your company, and then work to calculate which job should be assigned priority.
WSJF prioritization makes one BIG assumption, which is worth considering--especially in hardware development companies.
WSJF assumes that the critical resources on these projects are the same, and they are all busy on each project for the entire duration of that project.
In hardware development projects often the critical resources change over the course of a project. e.g., the EEs and MEs are often critical early in the project, with the most work to do on the critical chain. Later in the project, software engineers are critical, and the EEs and MEs are more available to work on the next project. This certainly complicates matters. However, it is still not overly complicated.
Ultimately the question is do you lose more by delaying Project A for Project B, or by delaying Project B to work on Project A? You delay Project A for the amount of time the critical resources will be busy on Project B. You delay Project B for the amount of time the critical resources will be busy on Project A. WSJF is the corresponding value when the critical resources are busy for the entirety of the project. If not, you just calculate it a little differently.
In this case, your higher priority is the option with the least total cost:
Ready to consider developing an Architectural Runway? WSJF can help you understand if it's worth the effort... check out our next post on WSJF, COD and Architectural Runways...
Free Template For Calculating Cost of Delay
Cost of Delay and How to Calculate It
Guide to Cost of Delay
WSJF and Architectural Runway
Don Reinertsen on cost of delay
Wikipedia on cost of delay
Editor's note: This post was originally published in 2015 and has been updated for accuracy and comprehensiveness.