If you only quantify one thing, quantify the cost of delay.
WSJF (Weighted Shortest Job First) 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 rather than just theoretical individual job ROI, that drives the best economic result. To that end, the SAFe WSJF icon illustrates how program backlogs are re-prioritized on every PI planning boundary using the weighted shortest job first via calculating cost of delay and job size (proxy for duration). Using this algorithm at PI boundaries continuously updates program feature priorities based on current business context, value, time, development facts, risk, and effort considerations. It also conveniently and automatically ignores sunk costs, which is a 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. WSJF is calculated as the Cost of Delay divided by job duration. Jobs that can deliver the most value (CoD) and are of the shortest duration are selected first for implementation. 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.
The impact of properly applying WSJF can be seen in Figure 1. (See [Ref 2 or 3] for the full discussion). The areas under the curve illustrate the total Cost of Delay in each case. Doing the weighted shortest job first delivers the best economics.
Cost of Delay
In SAFe, our “jobs” are the Features we need to deliver, so we need to establish both the Cost of Delay and duration of each feature. There are three primary elements that contribute to the Cost of Delay.
User-Business Value: Do our users prefer this over that? What is the revenue impact on our business? Is there a potential penalty or other negative impact if we delay?
Time Criticality: How does the user/business value decay over time? Is there a fixed deadline? Will they wait for us or move to another solution? What is current effect on customer satisfaction?
Risk Reduction-Opportunity Enablement Value: What else does this do for our business? Does it reduce the risk of this or future delivery? Is there value in the information we will receive? Will this feature enable new business opportunities?
Moreover, since we are in continuous flow, and we assuredly have a large enough backlog to choose from, we needn’t worry about the absolute numbers, so we can just compare backlog items relative to each other using the modified Fibonacci numbers we use in estimating poker. Then the relative costs of delay for a feature is:
Cost of Delay = User-Business Value + Time Criticality + RR-OE
Next we need to understand job duration. That can pretty difficult to figure, especially since early on we perhaps don’t yet know who is going to do it, or what capacity allocation they might be able to give it. So we probably don’t really know. Fortunately, we have a ready proxy, job size. In systems with fixed resources, job size is a good proxy for duration (if I’m the only one mowing my lawn, and front yard is 3X bigger than the back yard, the front lawn is going to take 3X longer to mow). And we know how to estimate job size in story points already (see Features and Stories). So finally, we have a reasonably straight forward calculation for comparing features via WSJF, as Figure 2 illustrates.
Then, for example, we can create a simple spreadsheet to compare features (three 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, and then calculates WSJF by numerator by job size.
The job with the highest WSJF is the next most important job to do.
1. With relative estimating, you fill one column at a time, set the smallest item to a one, and then set the others relative to that item
2. The job size (denominator) can be a relative number, or an absolute number based on story point estimates, but the units must be the same for all jobs.
3. The modified Fibonacci range above was selected because it enables valid comparisons using a single scale. It also spreads the results and helps reflect uncertainty, especially with respect to job size. In the case of job size, if a job size reaches 20 or more, it should really be split into smaller jobs before comparison.
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 anyway. Rather, you only need to rate the parameters of each job against the other jobs from the same 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.
A Note on Job Size as a Proxy for Duration
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 probably know enough about the job to use duration for have a more accurate result. (If I can get three people to mow my front lawn while I mow the back, then these jobs have about the same duration, but not the same cost.) But rarely have we found that to be necessary in the flow of value, in part because if there is some small error in selection, that next important job will make its way to use soon enough!
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Leffingwell et al. © 2011-2014 Scaled Agile, Inc.
Information on this page 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, visit the Permissions FAQ and Form.