By Bob Wen
Whether you are getting ready for your SAFe transformation or you'd like to prioritize any efforts that are too large or complex to be done in a single Sprint, WSJF provides a more objective measurement of what's best to do sooner.
In this post, we'll take a look at how to make the necessary changes to Jira to add the fields and the final field to display WSJF.
The hidden truth about implementing SAFe using Jira is that it is similar to buying assemble-it-yourself furniture from a certain Swedish purveyor: it will work well, it will look nice, but it will cost you "sweat equity".
When starting with a SAFe implementation in Jira, the temptation is to use the built-in Epic issue type and perform extensive modifications such as changing the issue type name to Feature, since an Epic defined in SAFe is not the same as what you get for the Epic issue type in Jira. You cannot do this without causing major problems, though.
Instead, we'll add the fields we need for WSJF to our Epic issue type. We won't go any deeper with the changes to the Epic issue type. Remember to use this issue type for our SAFe Features.
Fields of Dreams
As we saw in my previous blog article, WSJF can be considered "bang for the buck". The "bang" part of the equation is made up of three fields:
- Business Value - How important is what we want to produce?
- Time Criticality - How quickly does this value we want to produce diminish if we delay?
- Risk Reduction | Opportunity Enablement - If there's no immediate value, is it still worth doing because it may reduce risk or allow us to take advantage of new opportunities?
Each of these fields can be expressed as number fields in Jira.
Add it Up
The numerator for WSJF ("the bang") is going to be the sum of Business Value, Time Criticality, and Risk Reduction | Opportunity Enablement. To add our number fields in Jira, we'll use Jira Workflow Toolbox, an add-on that allows us to defined calculated fields dynamically. Other add-ons that do the same include Abacus (available for Jira Cloud) and Jira Misc Custom Fields.
Once Jira Workflow Toolbox is installed, we'll go into our screen to add a new custom field, making sure to select the correct type:
Once the field is created, we need to configure the formula for what our numerator will be. Jira Workflow Toolbox allows us to create the math expression for our custom field:
But what happens if someone forgets to enter a value for any one of these fields? Let's do some NULL checking:
Looks good. If any of those fields have a NULL, blank, or undefined value, Jira Workflow Toolbox will treat it as "0".
Jira Workflow Toolbox also includes an expression checker so you can test if your formula is syntactically correct.
Sizing the Job
Now let's take a look at the "buck" part of the WSJF equation. The denominator is known as Job Size or Duration. Though this can be a number field, it can also be the sum of the Story Points for each Story within our Jira Epic/SAFe Feature. So, let's make it a calculated field:
Here we can take advantage of pre-built functions for defining the issues list filter, getting the Story Points value from each Story issue type that the filter returns, and summing them together. Our expression in Jira Workflow Toolbox may look something like this:
Note that if we want our Job Size/Duration field to be truly reflective of the work done so far, we would decrease the number of Story Points as they complete. This would be done by changing the filter to look at Stories under the Epic/Feature that are still Unresolved.
Putting it all Together
Our final WSJF value is now merely the numerator divided by the denominator. Again, using a calculated field provided by Jira Workflow Toolbox, we define WSJF as:
We've included some NULL-checking, just in case.
We hope we've been able to show you a key piece of adopting SAFe using Jira. All it takes are the right add-ons and some ingenuity.