The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Hi everybody.
I sometimes have automations to set for clients.
I wanted to share one particular automation because I often see people on Community struggling with it and it saved me a lot of time.
Let's say you want to base your story points value on the sum of two other fields : Priority and Impact.
For example, you have the two following fields (with the associated story points) :
Priority => Cascading list with these possible values : Urgent (5), Major (4), Minor (3).
Impact => Cascading list with these possible values : Significant (6), Moderate (2) , Mild (1).
If you want to automate the calculation of the story points, you have to create three rules.
One which will calculate the value of a custom field called PriorityScore. Basically, it will look like this :
When value changed for Priority
If Priority = Urgent
Then update field PriorityScore = 5 (to do this you have to type {{#=}}5{{/}} in the PriorityScore bar)
Else-If Priority = Major
Then update field PriorityScore = 4 (to do this you have to type {{#=}}4{{/}} in the PriorityScore bar)
etc
Another one which will calculate the value of a custom field called ImpactScore. It is the same logic as the previous rule.
A third one which will sum both values and update story points.
When value changed for (PriorityScore, ImpactScore, Story points)
Then update the story points field :
{{#=}}{{issue.PriorityScore|0}}+{{issue.PriorityScore|0}}
The |0 determines the default value to avoid problems when some fields are empty.
In the settings for this third rule, don't forget to check the "Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule.".
Do you have any easy automation of that kind you often propose to your clients ?
Nice use of automation here Flavien. I can see myself using this rule to automatically change the ranking of issues on the backlog. With my Agile hat on, I'd argue though that a Story Point is not a measure determined by Priority and Impact rather consensus in the effort.
Hi, community! How about Age of WIP (work item age)?
(1) Add a custom numeric field, AgeOfWip
(2) Create the rule with a daily schedule, looking only at "in progress" and non-cancelled items
(3) Edit the custom field to calculate in calendar days
{{#=}}ROUND({{issue.statuscategorychangedate.toDate.convertToTimeZone(reporter.timeZone).diff(now.convertToTimeZone(reporter.timeZone)).millis}} / (1000*60*60*24), 3){{/}}
(4) Add the field to a dashboard, work items, reporting, board colors, etc.
(5) Use Age of WIP to monitor for stalled work, violations of Levels of Service, mis-use of Expedite urgency, etc.
Please look here to learn more about this measure:
https://www.scrum.org/resources/blog/4-key-flow-metrics-and-how-use-them-scrums-events
Very useful indeed. I will remember that ;) Thanks for sharing !
hi @Bill Sheboy - Can you pls let me know if there is any documentation to refer for the formula generation?
I need to find difference between current date and the "created date" from JIRA
Got the related info from https://support.atlassian.com/jira-software-cloud/docs/smart-values-date-and-time-functions/
And Thanks @Bill Sheboy , I'm done with configuring this custom field "Age of tickets" and can now include in various reports.. :)
Hi @Kiruthika
The link you provided is the one I use for date/time calculations, and the others for text and math are linked on that same page. For everything else, I end up creating lots of experiment rules with logging to figure things out. :^)
Please note that some of the date or date/time fields are text and not numeric. As in my Age of WIP example, those need to be converted to a date first.
Best regards,
Bill
These are brilliant. Anyone got any ways of using automation for Jira to transition issues based on Bit Bucket pull requests. There is functionality on Jira Cloud, but we have Jira Server and moving to Data Center.
Are you able to use incoming webhooks to do that? Please take a look here for more information for Jira Server/Data Center:
TL;DR: Using lookup issues, format and RegEx functions, count the issues meeting your criteria. Padding functions add the histogram data points. This works for up to 100 issues (due to the rule execution limit), and can only access the fields within the lookup.
In this example, let's frequency plot the hours issues were created. Here is an example output image.
Experiment to create a histogram of issue create times.
00:
01:
02:
03:
04:
05:
06:
07: ••••••••••••••••••••••••••••
08: •
09: ••••••••••••••••
10: •••••••••••••••••
11: ••••••
12: •••••••
13: ••••••••••
14: ••••••
15: ••••••
16: •••
17:
18:
19:
20:
21:
22:
23:
The how-to for the rule is:
<body>
<div style="font-family:courier">
<p>Experiment to create a histogram of issue create times.<br>
00{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^0$)").split(",").size.plus(2),"•")}}<br>
01{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^1$)").split(",").size.plus(2),"•")}}<br>
02{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^2$)").split(",").size.plus(2),"•")}}<br>
03{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^3$)").split(",").size.plus(2),"•")}}<br>
04{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^4$)").split(",").size.plus(2),"•")}}<br>
05{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^5$)").split(",").size.plus(2),"•")}}<br>
06{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^6$)").split(",").size.plus(2),"•")}}<br>
07{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^7$)").split(",").size.plus(2),"•")}}<br>
08{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^8$)").split(",").size.plus(2),"•")}}<br>
09{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^9$)").split(",").size.plus(2),"•")}}<br>
10{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^10$)").split(",").size.plus(2),"•")}}<br>
11{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^11$)").split(",").size.plus(2),"•")}}<br>
12{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^12$)").split(",").size.plus(2),"•")}}<br>
13{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^13$)").split(",").size.plus(2),"•")}}<br>
14{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^14$)").split(",").size.plus(2),"•")}}<br>
15{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^15$)").split(",").size.plus(2),"•")}}<br>
16{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^16$)").split(",").size.plus(2),"•")}}<br>
17{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^17$)").split(",").size.plus(2),"•")}}<br>
18{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^18$)").split(",").size.plus(2),"•")}}<br>
19{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^19$)").split(",").size.plus(2),"•")}}<br>
20{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^20$)").split(",").size.plus(2),"•")}}<br>
21{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^21$)").split(",").size.plus(2),"•")}}<br>
22{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^22$)").split(",").size.plus(2),"•")}}<br>
23{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^23$)").split(",").size.plus(2),"•")}}<br>
<br></p>
</div>
</body>
Explanation of what is happening:
00{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^0$)").split(",").size.plus(2),"•")}}<br>
There are several potential use cases for this one. The key challenge is the 100 issues processing limit; so if your use case fits in that limit I hope this can help you.
Best regards,
Bill
There does not appear to be a built-in way to determine if an issue is from a classic or next-gen project from inside of an automation rule. Projects have a "style" attribute, and this appears to only be available on the project list and in REST API methods at this time. When your automation rules have different behavior based upon classic or next-gen, it can help to determine this within a rule.
Automation rule details:
{{#webhookResponse.body}}{{key}}:{{style}}{{^last}}, {{/}}{{/}}
Next-Gen Projects: {{varProjects.split(",").match("(.*next-gen)").replace(":next-gen","")}}
References:
https://docs.atlassian.com/software/jira/docs/api/REST/1000.824.0/#api/2/project-getAllProjects
https://docs.atlassian.com/software/jira/docs/api/REST/1000.824.0/#api/2/project-getProject
We have a Celigo integration that takes time logs from Jira and pulls them into NetSuite, but all tickets need epic links. The problem was that our QA team was creating Bugs with a "relates to" link to the ticket it stemmed from, and so we were getting tons of errors since there was no epic link. (We can't use child issues, as you can only have one child issue type in Team Managed project and that is already being used for subtasks.)
I created this automation rule to look for the parent (epic) on a newly linked issue and add it to the Bug, as long as an epic link doesn't already exist. (The action is "Trigger Issue")
Hi Everyone, In this roundup we combine all the jira automation rules to sum up story points across different issue types. We start from the lowest level, summing up story points from sub-tasks t...
Connect with like-minded Atlassian users at free events near you!
Find an eventConnect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.
Host an eventYou're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events