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 ( [1] 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.

Details

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).

Figure 1. The economic effect of doing the weighted shortest job first

We can see from Figure 1 that the highest priority job is the job that has highest ratio of cost of delay over duration, so this teaches us to focus our efforts on the things that have the highest value that we can get out the door most quickly.

Cost of Delay for Epics and Features

Of course, applying cost of delay hinges on an understanding of how one calculates the cost of delay. For software, we posit that the cost of delay includes three components:

User|Business Value. Relative value in the eyes of the user/customer/business, including such considerations as “they prefer this over that”, revenue impact on the business, and any penalty (cost, market share…) for slow or late delivery. This may also include the business value of architectural features and epics as well.
Time Criticality. This parameter reflects how the User|Businees may decay (or CoD will increase) over time. Considerations might include upcoming deadlines; customers willingness to wait rather than adopt a different solution, and the effect on customer satisfaction and good will while the feature is not available.
Risk Reduction|Opportunity Enablement Value. This last element is an aggregation and proxy for two things: 1) the value to the business in reducing the risk of solution efficacy and/or the ability to develop future business value, and 2) the potential for new business opportunities that might be unlocked.

Taken together, these provide a fairly comprehensive view of the Cost of Delay for our Feature or Epic, and this formulation has proven its worth in many enterprise settings.

Job Size as a Proxy for Duration

However, we still need a proxy for the WSJF denominator, duration. Fortunately, we know how to estimate effort (the job size) for our Features and Epics, and we do that by sizing in story points. In addition, it is patently clear that, in most cases, bigger jobs take longer to do, so job size is an excellent proxy for duration.

WSJF Formula

And finally, we arrive at a formula for calculating WSJF as in Figure 2.

Figure 2. A Formula for calculating Weighted Shortest Job First

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.

Figure 3. A sample spreadsheet for caluclating Weighted Shortest Job First

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.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Last update: 4 May, 2013