Labeling tickets based on epics

[Mara Julin]

Im trying to set up a series of automations to label tickets based off their epic. In order to not have to create 1 automation for every epic, I was planning on setting up the automation to look for just an ending like "(A)" that we would just start adding to the epic names we'd want to categorize.

I'm testing this out and while the automation is working for the 4 categories I want (Bugs, interruptions, new features, maintenance) - it is applying all 4 labels for all the epics instead of just the ones I want - anyone know why or how I can set this up so it doesn't need to be updated?

This is the current setup for 2 of the automations and then an example of how for one of the epics all 4 labels still show up.

[Bill Sheboy]

Hi @Mara Julin 

Are you currently using the Labels in the epics for anything else?  If not...

As you are setting the Labels in the child issues of the epic, I wonder if you could simplify and just set the desired Label in the epic, and then copy to any child issues, with no need to parse the Epic Name.

Kind regards,
Bill

[Mara Julin]

Yeah I was initially thinking of this approach, but I wasn't sure if it would update any tickets that come in.

My goal is to create higher level categories for groups of epics. So for example the label "roadmap" would include epics: project epic 1, project epic 2, project epic 3. Or "tech debt" would include epics related to infrastructure changes.

In this way I can see sprint per sprint, what types of work are we completing. Based off this would you still suggest that way?

[Bill Sheboy]

No, I would not.  It seems you are trying to use Labels to represent groupings for hierarchy (e.g. roadmap) and classification (e.g. maintenance).

However you choose to do this, the key will be consistency as you are storing more than one type of information in the Labels field.  Other approaches to solve this would be to use Components for one of those classifications, or custom fields with selection lists.  The latter would make your automation rules (and reporting) easier to do.

[Mara Julin]

Thank you!

I am trying your custom field approach with a selection list, I just added it to my project screens and see it on my tickets, however when I go to edit the automation to edit that field it isn't coming up as an option, even when i search.

Any idea why?

[Mara Julin]

Also if you have suggestions on how this approach would make reporting easier I'd love to hear. I thought even with adding this I'd still have to export a csv and count how many story points we complete for each category (which is what I am trying to get to) but if there's a look that will do this for me I'd love to know.

For reference, I'm trying to get as close as possible to this template below. So far I haven't found any automated way to get the "rolled over points" row or the "committed points' column, but this was my thought process of how id at least get the "completed' points column across these categories for each sprint.

[Mara Julin]

Would this be the reporting view you'd use? The sum UP function in the dashboard options.

[Mara Julin]

Related question to this that I started on a different thread (thanks again for your help with this!)

As I'm thinking about adding in more automation rules, I want to be mindful of our monthly usage. Currently our usage is 2 rules that aren't done by these project specific automations (see rules below), although if i go this route I would be adding 20 additional automation rules (e.g one for each of these categories across 5 projects). Is there a trigger I should use for this project that would use less processing time? Currently this is using the "when sprint closes" trigger. 

[Bill Sheboy]

Hi, Mara.

Lots of questions I am trying to catch up with...please let me know what I miss.

Custom field edit: For some custom fields they are not listed in the drop-down fields for rule actions.  For edit, you may used the advanced edit with JSON.  Please look here for how to do that: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/

Reporting from rules: There is little support for custom reporting in Jira Cloud, and how you work-around this depends upon your frequency of need, cost limitations, and what you want to report. 

When you need such reporting often (and modify it a lot), please consider looking at the Atlassian Marketplace for addons for dashboards and reporting.  When you need it less frequently (or have cost limitations), you could export data to a spreadsheet...or...with an automation rule you could use the Lookup Issues action, custom fields, and emails to build some reporting.

For the sprint related measures you note (e.g. rollover points and committed points), marketplace addons can help.  You could also use sprint event triggered rules to gather the information.

Rule executions and triggering:  For the rule you describe as triggered on sprint completes and spanning multiple projects, that rule would be difficult to work-around without just cloning to projects.  My suggestion is to pause and consider what you are trying to accomplish with such rules, and if there is another way to solve them instead of global rules.  For example, those rules show editing the Assignee and Responsible For fields; if that is solely for reporting, can the reporting be altered instead of changing the issue data?

Thanks,
Bill

[Mark Segall]

Hi @Mara Julin - Can you please share the steps of the rule(s) so we can have more clarity on your end goal?  This would help in our ability to assist.

[Mara Julin]

Yep! I'll attach below, also including more context if it helps: 

My goal is to create higher level categories for groups of epics. So for example the label "roadmap" would include epics: project epic 1, project epic 2, project epic 3. Or "tech debt" would include epics related to infrastructure changes. In this way I can see sprint per sprint, what types of work are we completing. 

My hope though is that I only have to set up 1 automation for each of these things, and don't have to add a new automation whenever we add a new epic. Which is why I was trying to do the "(M)" at the end of the epic name for "Maintenance", etc.

[Mark Segall]

Thanks for the screenshot... It looks like it's just a matter of swapping the condition and the label action.  As it stands right now, it applies the label and then looks for whether the epic ends in (M).  So it will have applied the Maintenance label to all issues in that sprint, regardless of the Epic.