Throwback Thursday: How have you routed issues in Jira? #TBT

[#1]

It's Thursday!

Let´s talk Jira memories today, specifically routing of issues to different teams. One place that worked at had lots of teams and this was before JSM. The first iteration we did had 2 single select fields: "Specialty" and "Group". Then we built a whole bunch of filters and dashboards that were based off on these 2 custom fields. 

After a couple of years we didn´t feel that was working so we swapped those fields out for a cascade field "Groups" (yeah, we only added an S so it was a bit confusing at first). At another place, we used Components but I feel the downfall there is that one can select more than one Component yet there is only one Assignee (if one is using the auto assigning feature of Component, which we were). 

Soooo, how have you routed issues in Jira? What have you found to be successful?

Let’s make it a great Thursday!

KGM

[Dan Breyen]

Luckily now we're a small dev shop where there are only 7 developers.  And with 1 development project, it's just a matter of changing who is assigned to it.  At a previous job there were at least a dozen different projects, and even two different JIRA Server environments and it was certainly a challenge to make sure you got the right JIRA env, then the right project.  Moving JIRA issues was one of my favorite features at that job.

[Chris Iacovelli]

Labels and several custom fields within our company (Pod/Team, Biz Segment, Biz Lead, Biz Unit, ...) are key fields we use across our issue types and then dashboards are created around them.

Each has their place and each has their overload as we segment the tickets finer and finer.

Primarily, we use labels in our team to help route and associated tickets to work.

[Sue Wilson]

I recently created a JSM project and added a form with a 'components' single select field with only several options for the end user to choose from via portal.  This form field was linked to the Components field (NOTE: make sure the options added to the form are also valid options in the projects).  Based on the option the end user selects, I then use global automation to create a new ticket in the appropriate software project. 

While the ticket is initially created in the JSM project, once the automation creates the software ticket, you can either Close or Delete the original JSM ticket.  We chose to Close it for historical reference should we need to see what comes in to Engineering from these end users.  This is the last step of the automation, so no manual intervention is required at either end.

[said kouzibry]

If I recall properly, it was a rather complicated project where issue had a specific numerical ID entered into a field with validator to check it's correct, that ID would dictate (through sql query to another system) the issue type (not Jira issue type, a custom field) and that issue type would then determine which group gets assigned the issue (group field), then the issue would appear on the dashboards of all users belonging to that group then one of then can assign it to himself.

It was a mess and still don't know who made it that way and why, I'm glad I no longer have to troubleshoot systems like that.

[Summer Hogan]

We are using both Align and Jira and trusting the integration, which does not always work. We use the component field in Jira to tag all teams involved in an epic and use the Impacted Teams field in Jira to tag all teams involved that are in my Value Stream. It's been difficult lately trying to adopt Align and learn the new ways in Jira our administrator designed for us to implement SAFe. It's difficult and I need an actual guide to show what we do in Align and what we do in Jira. 

[Randy O'Neal]

We are an ~200 team member shop.  We have 9 distinct development/delivery teams, and we have a core "Funnel" project where our inbound new issues by default go to when not created internally by our own teams.  For example, our funnel project is TBF; as TBF issues arise, the product team and/or Scrum Masters will evaluate which of our core delivery teams should address the issue.  We work on a common product suite with web, iOS, and Android platforms, so it's usually not too difficult to ascertain which team should wind up with the issue.

We usually ask either the SM or the PO to pull the issue to their team; this ensures they are aware of the issue and it doesn't typically "sneak into the backlog".  We also have a Product Support team who will often create issues directly onto a given team's backlog, along with requisite communication to the SM and the PO... and sometimes the director as well, depending on the priority of the issue.

By asking the SM or PO to pull  the issue to the team, we largely avoid issues with communication.  We will typically pull issues to our refine/groom Kanban board for the team, so that the PO can then bring the issue to the team to refine and groom prior to the team scheduling the work.  At times, priority dictates we pull the issue straight to the team for immediate attention.

Hope this helps...

[Laurie Sciutti]

Team field (from Plans)....as well as splitting / breaking down issues that are being addressed by multiple teams...

[Dave Mathijs]

Routing

In Server/DC, we often used a combination of Support Teams (in Insight/Assets) and Assigned Teams (groups for notifications), sometimes added with an additional level (like department, internal/external) to route ITSM tickets to 100+ support teams.

Otherwise

I think that Labels are underused and underestimated in JSM. I use it to categorize requests, incidents, problems and changes in order to 'feed' the change log of linked Jira issues on a Confluence page.

For example: I have a page with all the custom fields created in a list with details. I then add a Jira filter below to list all the issues related to custom fields so that I have a change log of when custom fields were created, updated or removed.

[Ndane Elisha mankaa]

@hello @ Dave Mathijs  good day Sir im new into this Agile journey and im reading the scrum guide please can you add me to your group and also please is there free practice template that i cant be following on this community because i  cant see thank very much  i appreciate your help 

[Craig Nodwell]

Over the years.  Custom fields.  Labels.  One team one project.
Today, Advanced Roadmaps (Plans) and the Teams field.

[Craig Nodwell]

I just remembered one other situation, not that long ago.  Parent company finally showed up after a couple years of doing an implementation of a delivery pipeline that was running a Jira server instance, parent company had their own instance.  I federated the two systems, then used projects on both sides created rest endpoints, and scripted fields to manage the components, versions, and links via the application link used in the federation.  A lot of under the hood automation and screen behaviours with scriptrunner.  Testing projects spanned the enterprise and needed to log tickets against the parent or local companies teams.  At that time Portfolio was just becoming Advanced Roadmaps and the price was out of scope, so the above needed to be built. 
Today, having that built into DC and being able to leverage the Team field on the issues while managing capacity with project and shared teams in ARM is at my current client (one year in) making this so much easier to implement and gain adoption.
Looking forward to year 2 and clustering out the DC instance.

[Sanjog Sigdel]

Simple, I've implemented a Back to Developer custom field which increments by one whenever a ticket is moved back to ToDo and In Progress. Then I've a filter for the same. Now my widget display the issues that has been moved back to developer displayed in the dashboard. Now whenever a defect is logged the ticket is moved back to the developer and we discuss on that issue during our standup.

[Nikki Zavadska _Appfire_]

When I was working my first QA job we were a large team on 30 QAs - each of us responsible for testing different areas of the app.

We used labels and fix versions and statuses to filter out what's now ready to test.

Labels were identifying parts of the app, fix versions were showing the release candidates (there were 8 of them for each version in total) so you knew if the code was deployed to the test environment for the test :)

[Anthony Morais]

I remember one time they asked me to create a reminder for the operations team to send an email when there was maintenance, at first I got a little carried away, but we created two date picker fields "Start and End" and put them to an automation to check a JQL to monitor these fields, when he had 24 hours in advance he would send a reminder email.

[Dinesh Babu]

back in last decade or so,  we were requested create to excel macros for any kind of automation

[raj shaswat]

i created my own bot which will keep track of Jira Issue assigned to me and comment automatically based on field defined when i am out of office.

[John Funk]

We started with Labels and quickly learned that was not the route for use with all of the misspellings, case sensitive considerations, etc. So we switched to Components and were very happy with those. It brought a lot of structure for us and commonality in reporting. 

[Summer Hogan]

We use 2 main fields in Jira to route issues; Components and Impacted Teams. We use components in epics to tag teams that will have some dependency or impact on the epic. This includes teams inside of our ART and supporting teams. The Impacted Teams are those within our ART that are impacted. I also utilize the comments heavily in Jira and tag people so they know what is going on with an epic. 

[Sayed Bares _ServiceRocket_]

We have used many approaches, custom fields, components, labels, using automation to move tickets to different projects. My favourite was using custom fields with automation!

[Ram Kumar Aravindakshan _Adaptavist_]

Had to do this a couple of times. Mainly when customers lazily report tickets to the wrong product or wrong instance, i.e. instead of reporting for Cloud they report it in Server / DC.

[Mahesh Shinde]

We have setup the REST API call through script in Jira which will create ticket in particular project, it was working fine for Couple of months and after that some of the Jira admin member the change the field context for one of the required field which is available on create screen that results failing into the REST API call.

It took time to identify this issue but the lesson learn is to validate the changes in test before doing in live.

Regards,

Mahesh Shinde