SAFe WSJF in Azure DevOps

David Jobling
5 min readJun 16, 2021

We’re a Scrum team and we’re always looking for things to make us better. I’m actually the PO (albeit with a dangerous amount of technical knowledge) and so my focus is on refining the backlog, and importantly, the prioritization.

I’m doing a refresher course on SAFe and the WSJF topic came up and decided I’d like to use that to reflect a little more information over the backlog.

WSJF Fields and Calculation

To calculate the WSJF you need four numbers:

WSJF Formula — Scaled Agile Framework

If you’re using the Scrum Process Template in Azure DevOps then you already have three of them:

  • User-Business Value — Use the Business Value field
  • Time Criticality — Use the Time Criticality field
  • Job Size — User the Effort field

We’ll need to extend the Process Template to add two new fields:

  • Risk Reduction and/or Opportunity Enablement — Add a new decimal field called RROE
  • WSJF — Although we’re going to use an Azure DevOps extension we need to add a new decimal field called WSJF as the destination of the calculation

I want my WSJF at the Feature level however I’ve seen some implementations at the Epic level.

We’re going to use the WSJF Extension in the Azure DevOps Marketplace to provide the calculation. There are a few ways to do this in Azure DevOps but its always good if someone else has already done it. You’ll need to be an organization admin to do these tasks.

Once you have this installed you configure it to use the fields you defined above:

Configuration of the Azure DevOps WSJF Extension

Part 1 done. If you update and of the input fields on your Feature the WSJF will be calculated:

Feature Work Item fields where the WSJF is calculated automatically

Rolling up the Effort using Microsoft Flow

So this whole things works great apart from the fact we need to keep the Feature Effort up to date. In our team we maintain the Business Value, Time Criticality and now RROE directly on the feature. We plan and prioritize at a Feature level. But we estimate effort at the PBI level, children of the feature. The feature Effort is the sum of the Effort of it’s children.

Azure DevOps provides a roll-up view on the backlog to auto-calculate this total however that roll-up total is not available on the Feature work item and we can’t feed it into the WSJF extension.

AS with WSJF there are a variety of methods we can use to calculate this rollup but searching around for new options I was inspired by this post:

I used Flow a little while ago for some integration work but it was a little immature; time to give it another go.

Using this post as a basis I was able to create a flow that was

  • triggered by a Work Item change (in this case a PBI)
  • an action to get all the children of its parent (all the PBIs of the feature to which the PBI that was changed is a child)
  • loop though the children and total up the Effort (using a local variable)
  • set the effort of the parent of the trigger work item (the Feature)
Visualization of the Roll-up Flow

A few tips that may help you setup this flow.

I originally had a few more steps trying to get the Work Item Id of the parent (the feature) but it turns out you can just use the Parent field of the trigger item, no need to get the ID of that parent:

You can use the Parent field value of a Work Item as the Work Item Id

I went around a few implementations on calculating the effort total for the feature. Originally I had it to zero out the Feature Effort and then increment it with each child. This didn’t work since it seemed to use the non-zeroed effort as a base and it was cumbersome and ended up with a lot of updates to the feature.

I then re-found variables and it is much simpler:

Incrementing the TotalEffort variable value with each child PBI

This avoided the need to use a formula such as this one

Flow has improved a lot in the last few months with a much greater variety of connectors. My company supports these as a way to help us improve our own productivity and while this uses some premium connectors (Azure DevOps) the value of keeping those effort fields up-to-date more than makes up.

It’s an investment but if you can convince those with the purse strings you shouldn't have much issue in demonstrating value.

--

--

David Jobling

David is a Sr. Director in Technology Leadership at Avanade. Keen interest in Agile Delviery, Modern Engineering and DevOps/Automation