Trying to simplify WSJF (weighted shortest job first ) – Simple rule is that one with higher WSJF is given highest priority for delivery.
We all understand that feature/item which has highest COD (cost of delay) should be taken first so now let’s consider 3 scenario :
Scenario 1: 3 Feature with same COD – which one should we take first – good idea to take one which can be delivered fastest or required least effort or has smallest Job Size – let’s see what WSJF says
Hurray!!!! the WSJF math meets the common understanding.
Scenario 2: 3 Feature with different COD but same job size– which one should we take first – obviously one with higher COD should be taken first – let’s see what WSJF says
Hurray!!!! the WSJF math meets the common understanding.
Scenario 3: 3 Feature with different COD and different JOB Size– which one should we take first – obviously one with higher COD should be taken first – let’s see what WSJF says and why
Opps!!! it’s a conflict. Considering COD only the order should be First B Then C and last A but the WSJF math says it should be C then B and then A let’s find out why
Considering Job size as number of days to complete the work. And cost of delay as $$ value lost by every day of delay in delivery. Start date is 1st Jan
Scenario 1: Order of execution considering COD only B then C then A
Scenario 2: Order of execution considering WSJF C then B then A
So it’s clear now that looking from an overall business economic perspective WSJF scientific methods works better in maximum cases, though there can be exception.
Important Points to consider :
1. Prioritization is an ongoing activity and is done considering 1 or max 2 Program Increment (PI). It need to be done minimum after every PI and may change even before start of sprint depending on market demand or sometime dependency and technical challenges. We should keep it fixed for a Sprint – no changes should be done in a running sprint.
2. As prioritization is an ongoing activity so should my Job size change after every sprint for a feature – NO because doing this will ignore Sunk cost (cost already invested or to be invested in future) which is a key economic principal in lean.
3. The numbers given for each attribute in COD or Job size are comparative meaning we first need to choose a base in the list which is 1 and then decide what other are related to base. This really kills the dependency on exact estimation for job size or financial data for considering time critical or business value. Solves the purpose.
4. Why we take Fibonacci series – to make the difference more visible , after all they are estimates and not real number and purpose is to make the difference visible.
5. Why not to have a single number for COD and break it into 3 factors – Answer is in definition of factors consider in calculating COD and chances are high that we will miss on one or other aspect if we go with one number approach:
COD = User business Value + Time Critical + RROE Value
User Business Value : Do our user prefer this over that ? what is the revenue impact on our business ? is there a potential penalty or other negative impact of we delay
Time criticality : how does the user/ business value decay over time ? is there a fixed/hard deadline ? will customer wait for us or move to another solution ? Are their critical path or milestone impacted by delay on our delivery ?
RROE (Risk reduction – opportunity enablement) : What else does this do for our business ? does this reduces the risk of this or future delivery ? Is there a value in the information we receive ? will this feature open up new business opportunity?
Like any other good process WSJF also have its own gaps and improvement area but it helps to scientifically prioritize the backlog in most cases , considering the best economic output.
Please share in comments scenario where WSJF did not work and what alternate prioritization technique helped to serve business interest best.
