Assigning sequential priority based on WSJF score in Jira Automation

[Andreas Söderberg]

I’m trying to automate the prioritization of issues based on their WSJF (Weighted Shortest Job First) score using Jira Automation. Specifically, I want to:

1. Fetch all relevant issues using a Lookup Issues action that retrieves issues with a WSJF score, sorted in descending order.

2. Assign a sequential priority or rank (1, 2, 3, etc.) to these issues based on their WSJF score, with Priority 1 going to the issue with the highest WSJF score.

The goal is to dynamically number each issue based on its position in the lookup result, assigning a unique number to each issue. I tried different methods but have yet to achieve this.

What I’ve Tried:

1. Using Smart Value {{index}}: I tried using {{index.plus(1)}} within a Branch rule to reference the position of each issue in the lookup results, but this clears the field instead of assigning a sequential number.

2. Creating a Custom Variable (priorityCounter): I created a variable to act as a counter that increments for each issue within the Branch Rule / Related Issues loop, using {{priorityCounter}}. This didn’t work as expected, as it didn’t apply unique numbers to the issues.

Desired Outcome:

• Fetch issues via JQL (e.g., all issues with a WSJF score).
• Sort them by WSJF score in descending order.
• Loop through the issues and assign Priority 1, 2, 3, etc. based on their WSJF score.
• Ensure each issue gets a unique sequential number based on its WSJF rank.
  
  

Q: Is there a way to assign unique sequential numbers to issues based on their order in the lookup result using Jira Automation? Any insights into why the {{index}} smart value or the counter method is not working as expected would be greatly appreciated.

[Bill Sheboy]

Hi @Andreas Söderberg -- Welcome to the Atlassian Community!

My apologies in advance for my long response :^)

I agree with the insights and suggestions from @Walter Buggenhout and I understand the coordination "priority" problem you are trying to solve for subordinate work that spans teams for delivery at larger scales when there are work dependencies.

In my understanding...as weighted, shortest job first (WSJF) was originally described by Donald Reinertsen--rather than the interpretations by other "framework" authors--once selection occurs of the first work item(s) for a planning timeframe, the remaining scorings are living values...updated over time as things evolve.  Having the coordinating number for the N-items selected for delivery only helps if there is enough capacity to work on the 1st, 2nd, etc. items in parallel and the teams need to coordinate delivery.  That coordinating number could be the WSJF score or a number unique for the planning timeframe.

Let's say you want the unique number, or index from the list, rather than using the WSJF.  That is possible using automation rules, and (please note well) could potentially get out of sync as soon as a work item carries over a delivery timeframe boundary.  If we assume that does not happen...

• use Lookup Issues to gather the items with the WSJF scores, in ascending order by score
• create a variable to build a delimited list of keys and their index (changing it to 1-based)

{{#lookupIssues}}{{key}}:{{#=}}{{index}}+1{{/}};{{/}}

• branch on JQL for the same issues from the lookup
  • using dynamic searching methods with regex, search for the key of the current issue in the variable with the match() function, and extract the saved index number
  • use that value to update the issue

Again, I would recommend just using the WSJF value rather than creating a new value.  And perhaps a root cause to solve is eliminating the dependencies so the coordination number is not needed at all in the future.

Kind regards,
Bill

[Andreas Söderberg]

Hi @Bill Sheboy,

Thank you for your input! I appreciate it, even though I'm late in replying. Here’s what I have so far. Any guidance you could offer would be greatly appreciated.

Rule Setup (method 1)

1. Scheduled Trigger

2. Lookup Issues: I use the Lookup Issues action to retrieve relevant issues, sorting them based on WSJF scores. This creates the ordered list I need for priority assignment.

3. Create Variable: To manage ranking, I generate a delimited list based on your feedback to generate issue keys with their indices (starting from 1):

 {{#lookupIssues}}{{key}}:{{#=}}{{index}}+1{{/}};{{/}}

This results in a list like ISSUE-1:1;ISSUE-2:2;ISSUE-3:3;, where each key is associated with a priority number. – So far so good.

4. Branch Rule: I use a JQL Branch Rule to iterate over each issue returned by the Lookup Issues query, updating each issue individually.

5. Assigning Rank: Within the branch, I attempt to match each issue’s key within the delimited list created earlier to assign its rank.

 {{issueKeyIndexList.match(issue.key + ":(\\d+)").substringAfter(":")}}

This is where I keep failing.

While the match() function works in isolated tests, it’s been inconsistent in the full rule execution—sometimes failing to match dynamically as expected. It seems there may be limitations with handling variables dynamically within match() when iterating through issues in a branch. I’d appreciate any advice on making this dynamic matching more reliable or alternative approaches to ensure sequential ranking without these inconsistencies.

Rule Setup (method 2)

I have tried another method as well, which I will attempt to explain here:

Steps in the Automation Rule

1. Scheduled Trigger

2. Lookup Issues

3. Create Variables for Issue Keys and Priority Counter:

• Issue List: A variable called issueList is created. It stores the list of issue keys returned by Lookup Issues in a semicolon-separated format (ISSUE-1;ISSUE-2;...). This allows the rule to reference each issue individually during iteration.

{{#lookupIssues}}{{key}};{{/}}

• Priority Counter: Another variable, priorityCounter, is initialized with a value of 1. This counter will be incremented for each issue, providing a unique sequential priority number.

4. Advanced Branch to Iterate Over Issues:

• Using Advanced Branching, the rule splits issueList by semicolons, looping through each issue key individually.

5. Setting Priority and Incrementing Counter:

• Edit Issue Fields: Within the branch, the Edit Issue Fields action sets each issue's priority field (or WSJF field) to the current value of priorityCounter.
• Increment Priority Counter: After updating an issue, the priorityCounter variable is incremented by 1, ensuring the next issue receives the next sequential priority.

{{#=}}{{priorityCounter}} + 1{{/}}

Much like method 1, this ends in failure, as the branch fails to iterate on the incremental priority counter, which results in all issues getting 1 as priority. I hope you can help steer me in the right direction as I'm backed into a wall and don't know how to proceed.

Thank you again for your help!

[Bill Sheboy]

Hi @Andreas Söderberg 

Just following up on the dynamic match() expression question you asked.  That must be built with Create Variable first for use in the function.  Please look here for some examples of that:

https://community.atlassian.com/t5/Automation-articles/Automation-concepts-Dynamic-searches-within-a-list/ba-p/2834235

Thanks,
Bill

[Andreas Söderberg]

Hey @Bill Sheboy

Thanks for following up. After a lot of research and trial and error, I figured out how to make this work. The solution involved expressing the proper smart value.

The solution is this smart value effectively moving away from the match() logic.

{{issueKeyIndexList.substringAfter(issue.key).substringBefore(";")}}

Thank you for the guidance! It has helped me find the structure and means to solve this. Even though it may not be the most elegant solution, it helped solve the client's needs.

Best regards,

Andreas

[Walter Buggenhout]

Hi @Andreas Söderberg and welcome to the Community!

For assistance with automation rules, please share a full screenshot of your automation rule so we know where you are and where the issue might be situated.

Apart from that, I have some doubts about your use case in itself. Is there any reason why you can't simply pull a list of your issues and sort them by WSJF score just like that, without trying to add a unique rank based on that? I would expect you would then want to use that to somehow rank your issues by, but I don't see the added value (I am probably missing something) - plus you would need to recalculate your ranking all the time after any change to your list of issues, which might generate a lot of automation rule executions. You didn't mention what plan you are on, so you may have a limited volume available ...

Did you know that Jira Product Discovery has built in calculated fields that can automatically re-rank ideas (the product does focus on product ideation, with just a link to delivery) - by default based on impact/effort scoring, but you can define your own calculations.

Hope this helps!

[Andreas Söderberg]

Hello @Walter Buggenhout 

Thanks for the reply. I understand that this use case might seem a bit confusing at first, so let me provide more context.

I have already implemented a list of issues ranked by WSJF score, and everything works fine in terms of visibility. We have a dashboard where we can see all initiatives ranked by WSJF score, so on that level, we’re covered.

However, the challenge arises when we break these initiatives down into specific issues across multiple projects. From each initiative, we launch several issues that are assigned to different teams or functions depending on who needs to execute tasks to complete the initiative. These teams often work in their own projects and backlogs, and they aren’t always aware of the WSJF ranking of the initiative that their issues are tied to. 

While the transparency is there, it requires several manual steps for a team member to check the linked initiative, compare it to the ranked list, and then figure out its importance. It’s not practical for everyday work, especially when people are focusing on their own backlog.

With the automation I’m trying to create, we aim to push down a priority number to the individual issues based on the WSJF ranking of the initiative they belong to. This would make it easier for teams to see, at a glance, how critical their issues are in the bigger picture and help them prioritize their work accordingly.