What the WSJF… now w/ JPD… OMG!

Are you amongst the t̶h̶o̶u̶s̶a̶n̶d̶s̶ hopefully more than 1 people globally who were thrilled to read my guide on using Automation for Jira to calculate WSJF but are now experimenting with Jira Product Discovery? Good news for those of you who’ve spent countless sleepless nights worrying about this vital topic — here’s some updated guidance!

TLDR: For now at least, Atlassian doesn’t let you create number picker fields in Jira Product Discovery, so doing WSJF with fields constrained to a Fibonacci sequence or similar requires a bunch of config. Read more for the config.

What the WSJF?

If you’re wondering what WSJF is this isn’t the article for you, but luckily this very thorough and informative one is:

WSJF - Scaled Agile Framework

Full transparency — I know lots of people who swear by WSJF and find it super useful, but personally I still think a simple Value / Size calculation is ample and far simpler to understand. You can use this article to do that also, but let’s go for the full fat solution…

Theresa May might not have made the precipitous run if only she’d known to prioritise using JPD…

Step 1: Configure your input fields in Jira Product Discovery

Configuring fields is easy peasy in JPD, and it’s just as simple to make them pretty (and why not do that?). For our example we’re going to setup the following fields using a single select field type:

• User-Business Value
• Time Criticality
• RR | OE (Risk Reduction and/or Opportunity Enablement)
• Job-Size UNLESS you’re doing our T-shirt size hack below — if you’re doing that, set this up as a NUMBER field or the maths will fail

Use the options 1,2,3,5,8,20 as per the Scaled Agile inc guidance. Make sure to include:

• Colour coding (this will be handy later I promise)
• An emoji… because it looks nice in the headers and humans like pictures
• A description — not everyone know what the lingo means… and they might appreciate a hint before they ask you

Optional Step 1a — But my teams like T-shirt sizing at a high level! Fibonacci is for their stories

I’m a fan of t-shirt sizes at a high level. If you’re like me, you’ll want to offer a T-shirt size field as a single select — use the same steps as above but make sure you offer the whole range of XXS — XXL. Those cunning amongst you will note you now have the same number of options as our modified Fibonacci sequence fields.

We can now use our old friend Automation for Jira to translate these sizes into the Fibonacci-sequenced Job Size field in the background so your teams don’t have to. Create a trigger for your JPD project(s) where a value change for the T-Shirt Size field kicks off some branches with an IF check that populates the Job-Size field to suit. Here’s an example for how that looks for an XS T-Shirt Size updating the Job-Size to 1:

There’s probably a smart way to do this without multiple branches but I found this quick to implement

REMEMBER: For this to work later in our maths, the Job-Size field must be of field type Number

Step 2 — create your calculators

I thought I’d nailed this using JPD’s calculation fields until going away… putting the kids to bed… and then noticing I hadn’t.

The bad news = JPD’s calculation field types now won’t sum your nice user friendly Fibonacci pickers. Try it — everything will be counted as 1 😩

The good news — Automation for Jira can fix things.

We’re going to create 2 automation rules to calculate the Cost of Delay and WSJF field using the same logic as in my original article.

Calculated field 1: Cost of Delay

This one is fairly simple but there’s a gotcha if you’ve used a symbol like | in your field name as SAFe shows — as with so many bugs in so many projects, special characters = problems 🤦‍♂️

Create your automation to trigger of value changes for the relevant fields. When it comes to editing the Cost of Delay field, make sure to wrap anything containing those lovely special characters in “” — in my example this means my expression for editing the field is:

{{#=}} {{issue.User-Business Value}}+{{issue.Time Criticality}}+{{issue."RR | OE"}} {{/}}

…so your rule should look something like this:

Check if seems to work, and then you’re on to your next fun and games

Note: This simpler config means that if you go back and delete one of your CoD inputs, the CoD calculation will persist. If you don’t want this, you can introduce some IF statements in branches chat clear the content if any of the fields are empty… but it gets very complex. Try this way first.

Calculated field 2: WSJF

We’re finally there! The point of the article. It’s actually really simple… if you’ve done all the hard work above, just create a calculated field with Cost of Delay / Job-Size and you’re done — yay! Don’t forget a nice emoji

Bask in the glory of your WSJF

If you’ve gone for the T-shirt size approach you can hide your sneaky Job-Size field now — you should have a lovely working WSJF-o-meter a bit like this:

You can make things even fancier using JPD’s matrix feature — I’ve played with mapping T-shirt size and Cost of Delay to the Axis here and WSJF to the Size of the blobs — this handily means the biggest blob is what you should pick up first. Try out different combinations and see what works best for you (NB: unless you invent a transdimensional matrix with 4 axis, you can’t do WSJF on one view… yet anyway)

…and that’s it. Complicated but sort of satisfying once you get it right.

Now maybe go back to Value vs Size like I said at the start eh?