Today I was in the SAFe Agile Training Course (Scaled Agile Framework by Dean Leffingwell) run by Rally Software and they introduced the concpt of prioritisation using the Weighted Shortest Job First (WSJF) Method. This is something that came out in 2009 in work by Don Reinersten.
Normally we prioritise based on business drivers from Senior Stakeholders, Product Owners, already known critical paths, what makes "sense" to us as a Project Manager, or who is shouting the loudest. The WSJF Method however gives another dimenstion to this by exploring the opportunity of multiple factors of value being combined together into a formula to give an implementation order.
As an intro some basic concepts such as "shortest job first" and "highest cost of delay first" can be combined to give a weighted cost of delay to enable quick prioritisation to reduce overall cost of delay. The Feature with the highest weighting by dividing CoD by Time should be done first, and if there is a tie, then the shortest job should be done first by default to deliver value faster.
CoD / Time (effort) = Weighted Cost of Delay
How cost of delay is actually defined is somewhat arbitary. It could be based on lost revenue, loss of potential earnings, market share, competitor advantage, reputation or a range of other factors. What is important is that a standardised approach is taken to giving it a value, Just like complexity the 1,2,3,5,8,13 scores seem to work well, with 1 being the least cost, and 13 being the most.
To step into the full calcuation for Weighted Shortest Job First (WSJF) and the cost of delay some further thoughts need consideration:
"User / Business Value" - what is the relative value of the Feature in the eyes of the business or the customer (again 1,2,3,5,8,13 is a good scale with 1 being low value and 13 being high). This can include revenue impacts or penalty costs if appropriate.
"Time Value". This measure deals with the "need" of delivering something in a timescale. For example, if you were replacing the bathroom your own house, it may well be prudent to get a toilet in quickly and less urgent to fit a basin if there was a sink in the kitchen that could be used for washing in the short-term. There are a range of similar scenarios in the business world where Features can be considered in a similar way (albeit with potential loss of contract earnings, or loss of customers as the repercussion instead) and again the 1,2,3,5,8,13 scale works well with 1 being a low "need" and 13 being highest "need".
"Risk Reduction & Opportunity Enablement Value"
This is the last part of the calculation input and gives a relative value for the need of a business to eliminate risks earlier or the potential for new business opportunity to be derived from the Feature (therefore not having its own discrete "business value" but enabling it elsewhere), and therefore gives some credit to the value of the risk elimination (1,2,3,5,8,13 scale again). Ultimately, some projects have low financial value themselves however have significant influence on lowering risk to the business or enabling future opportunity, this is what this one is about.
This one is straightforward - the estimate of length of time needed to implement the Feature (again can be a relative estimate using 1,2,3,5,8,13 or a real value in Months perhaps if it is easier).
The formula for Weighted Shortest Job First (WSJF) is as follows:
. User Value + Time + RR&OE Value
WSJF = ----------------------------------------
. Job Size (length)
The resulting WSJF scores can then be taken as a proposal for implementation priority order (Highest result number first) and will in some circumstances show otherwise hidden or not considered implications within the Feature-set (or Epics) to be implemented. The idea behind all of this is to deliver the lowest Cost of Delay to the business for features, epics, and even stories.
I have my reservations about how far down a Programme of work this can cascade. I can see it being a really useful tool at a portfolio level and also in the emerging Business Model Generation World. I think at an implementation level, decisions will have been made within the themes and high epics, and by the time it hits a Scrum team this will simply be a priority number in the backlog.
More on the Scaled Agile Framework to follow..