Prioritize (verb) To arrange or list a group of things in order of priority or importance. Wiktionary.com
Prioritization and scheduling are closely related activities with some key differences.
Scheduling too early can lead to waste and missed opportunity. Many fall into this trap as they don't fully appreciate that Weighted Shortest Job First (WSJF) is a scheduling strategy.
You can observe a classic scheduling algorithm in restaurants. For the most part, requests are processed in the order in which they are received; also known as first-come-first-served (FCFS). First-come-first-served works well for restaurants, airports and highways as the flow units are roughly the same size and of equal value.
In product development, the units of flow vary greatly in size and value. It makes sense to do the most valuable unit of work first. But, what if the most valuable unit of work is really large and it takes a very long time before we realize that value. Perhaps in that same amount of time we could do five small units of work with much larger cumulative value.
When scheduling, we need to consider the time it takes to realize value in order to ensure we are maximizing value throughput.
A scheduling strategy well known to many in the Agile community is Weighted Shortest Job First introduced by Don Reinertsen in The Principles of Product Development Flow (2009). Weighted Shortest Job First (WSJF) is calculated as Cost of Delay (CoD) divided by Duration.
WSJF can be a great aid to help maximize economic return from your portfolio. WSJF also introduces a lever that can greatly improve flow efficiency. With WSJF, huge initiatives that used to block the flow of value now have a low WSJF score and get bumped further down the to-do list.
This might seem problematic if that huge initiative has very high value. However, those passionate about the value of the proposed initiative will seek positive ways to influence the WSJF score by reducing the effort. This is most likely through: a) breaking down the initiative into smaller parts ; b) looking for wasteful features and gold-plating that can be safely discarded. If we can organize to get the highest value into the smallest possible component we will have identified our MVP.
WSJF has its limitations. We should not look at every decision through a WSJF lens.
WSJF does not work well when we have a large variance in value and/or duration. Think about the decisions you make in your household. Yes paying the utility bills, the mortgage and buying food all have high value but if you never change the filters on your HVAC system eventually something bad is going to happen. Like your household budget, create separate investment categories for like things and then use WSJF within those categories.
Early in the product lifecycle, especially when innovating, there will be enough uncertainty about who and how that any estimates about duration will be unreliable for decision making. Where this might be the case, don’t use WSJF to rank, use Cost of Delay. Or, in other words, don’t use a scheduling strategy when you are not scheduling.
Lastly, a word of warning. SAFe advocates using job size (level of effort) as an approximation for duration. This is a good approximation when flow efficiency is very good (minimal value-stream delays). Ironically, poor flow efficiency is one of the reasons why many adopt Agile and SAFe.
To sum up:
WSJF is a scheduling strategy used to maximize value throughput
WSJF can be an effective lever to help us identify our minimum viable product
Organize your backlog items into investment categories so we use WSJF to compare apples with apples
WSJF can be counter productive early in the product lifecycle
When you are not scheduling, don’t use WSJF (a scheduling strategy) instead use Cost of Delay
Be careful using WSJF when your flow-efficiency is poor. Only use job size as an approximation for duration when there is a good correlation