Wednesday, 9 January 2013

Weighted Shortest Job First / WSJF - a bit of the SAFe Framework (Scaled Agile Framework)

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.

"Job Size"
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..


  1. The basic idea behind WSJF is to come out with a prioritization process WITHOUT incurring the costs of "detailed estimates".

    Companies have started realizing that detailed estimates is what cost them most and that their prioritization process is mostly based on this sort of variable.

    The problem with that is that they de facto initiate work in the continuous flow of delivery, work that interrupts "already prioritized work". It is not only very costly in the forthcoming projects but also costly in the running projects (via work interruptions). On top of that, it simply increases the Project Lead-Time.

    Companies needed to find another way to start working and they have done that via a simple and arithmetic formula to weight projects against each other (Portfolio Engagement Rules "IN").

    1. Your central point seems to be that WSJF works fine without "detailed estimates". I'd agree with that.

      The problem I see though is that we seem to have focused entirely on estimating the cost and time, but almost nothing on the value side of the equation – being mostly driven by the HiPPO.

      We need to be careful though not to throw the baby (estimates of value and rough size) out with the bathwater (inaccurate and wasteful predictions of dates or cost).

      Estimates are hard, but worthwhile doing:

      I've also noticed that the people who are most afraid of estimates are those who have been on the receiving end of their abuse. The reaction is understandable, but that doesn't make it right:

  2. Good post. Thanks for sharing.

    I do think we need to distinguish between the SAFe interpretation of WSJF and what Don actually recommends. In my view these are quite different and the SAFe interpretation has a few challenges, and misses out of much of the value to be gained by quanitfying Cost of Delay

    1. This comment has been removed by a blog administrator.

  3. What I like best about this approach is it leverages the core idea of comparing the ROI (return on investment) of various tasks as a way of prioritizing. The thing that brings the most value for the least effort should be done first.

    I also like some of the specifics above about calculating value and the emphasis on NOT getting detailed estimates up front. It's not that estimates have no use, it's that it's a waste of time to do (detailed) estimates on things you haven't yet prioritized.

    I have a whole presentation these core concepts that was very popular at ProductCamp Boston a couple of years ago:

    1. Agreed Bruce, I think it helps if people understand the cone of uncertainty and where they are within it when making any sort of "estimate" at a point in time. Detailed estimates can often slow processes down, and not actually add any more value.

  4. Job training programs are advantageous for each part of your work and in this way it is significant that you be dependably watchful for different job-training programs. find here