If you only quantify one thing, quantify the cost of delay.
– Don Reinertsen
Economic Prioritization with Weighted Shortest Job First (WSJF) Abstract
The SAFe Framework is intended for application in situations where a number of teams are engaged in ongoing, continuous development—a flow of products, applications, services, etc.—that make up the enterprise’s value streams. As such, it avoids the overhead and delays of the start-stop-start nature of traditional projects and programs, whereby various project authorizations and phase gates are used to control the program and its economics.
While this continuous flow model helps eliminate delays and keeps the system lean, we do have to ensure that the program’s priorities are constantly updated, so that the value derived from the program provides the best economic outcomes for the business. In flow, it is job sequencing (  chap. 13) rather than just theoretical individual job ROI, that drives the best economic result. To that end, the SAFe “weight” icon illustrates how program backlogs are re-prioritized on every PSI planning boundary using the cost of delay and remaining job size. The algorithm used has the catchy title of “Weighted Shortest Job First” (WSJF). Using this algorithm at PSI boundaries continuously updates program feature priorities based on current business context, value, development facts, risk, and effort considerations. It also conveniently and automatically ignores sunk costs, which is another key principle of lean economics.
Reinertsen [Ref 2] describes a comprehensive model called weighted shortest job first (WSJF) for prioritizing work based on the economics of product development flow. When applied in SAFe, the model supports a number of additional key principles of product development flow, including
- take an economic view
- ignore sunk costs
- if you only quantify one thing-quantify the cost of delay
- economic choices must be made continuously
- use decision rules to decentralize economic control.
A summary of the recommended model appears in Figure 1 below. (See [Ref 2 or 3] for the full discussion).
Moreover, since we are in continuous flow, we needn’t worry about the absolute numbers. Rather we just compare jobs in the backlog to each other using a relative scale. For example, a simple spreadsheet to compare three jobs (features in this case) is shown in Figure 3.
To use the spreadsheet, the team rates each job relative to other jobs on each of the three parameters (note: with relative estimating, you do one column at a a time, set the smallest item to a one, and then set the others relative to that item), divide by the size of the job (which can be either a relative estimate, or an absolute number based on the estimates contained in the teams’ backlog) and calculate a number that ranks the job priority.
A Note of Caution: However, we do have to be careful about the size proxy we chose for duration. If availability of resources means that a larger job may be delivered more quickly than some other job with about equal value, then we can adjust the denominator to job duration to have a more accurate result. But rarely have we found that to be necessary.
One outcome of this model is that really-big-important jobs (like architectural and business epics) have to be divided into smaller-pretty-important jobs (like features) in order to make the cut against easier ways of making money (i.e., small, low risk features that your customers are willing to pay for now). But that’s just Agile at work.
And as we have described, another advantage of the model is that it is NOT necessary to determine the absolute value of any of these numbers, as that’s a fool’s errand. Rather, you only need to rate the parameters of each job against the other jobs from the backlog.
And finally, as the team’s backlog estimates should include only the job size remaining, then frequent reprioritization means that the system will automatically ignore sunk costs. Since the implementation is incremental, whenever a continuing job doesn’t rank well against its peers, then you have likely satisfied that particular requirement sufficiently so that you can move on to the next job. That’s Lean and Agile ROI.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 25 Oct, 2013
This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact firstname.lastname@example.org.