Best practices for grouping support requests in Jira?

[Stephanie Dietrich]

Currently, we are using Epics to organize project work.  We also receive recurring, related support requests that are also grouped by epics (Example: Create new job in Oracle for Technician, Create new job in Oracle for Manager, etc.)  The work is ongoing, and the epic won't ever close because the requests are related to supporting a process.

We want to keep project related epics and support related epics separate, as we only want to see project related epics on our roadmap.  In the interim until I find a better solution, I'm using labels to note that the epic is related to support. 

It doesn't seem like best practice to just leave these support epics open indefinitely.  Does anyone have suggestions on how to use Jira to group support requests (similar to work requests that might come through a Help Desk)

Thanks!

[Charlotte Prescott]

You could create a custom field, this could have a drop down field which map to your current epic names. You could then setup automation if appropriate so that when one is raised with a certain summary it auto applies the right choice for that field, as an example.

[mjswart]

We added a custom field to categorize our JSM requests. Not sure if this is best practice, but it gives us the ability to extract and view data based on the categories. There are a couple gadgets (pie chart to see how many in each category and 2D statistics to see which agents have worked on which categories) that we find helpful. 

[Kevin Dolhay]

Agree with this on the custom field option.  Simple solution and way better than labels.

Regarding the issue of epics that never close, I would have yearly epics and if they have stories that remain open at the end of the year, mass update and associate open ones to a new epic if it is important to close them out.  I'm not sure the real need to close out the epics if you are managing the work at the task/story level.

[Felix Malinis]

Have you looked at Services? It helps us keep track of requests that pertain to certain groups/products/functions within our organization.

[Samina S_]

You could create Epics for Every Quarter & close them as the quarter ends eg: Epic Summary = 2025 Q1 Support Requests

[Anne Saunders]

We have a big fat process that we use to keep these kinds of things separate. It would be a novel to write it all out here, but I'd be happy to chat through it with you if you like. 

The tl;dr (of the novel I didn't write 😅) is that per product we use one Jira project for dev and a separate Jira project for support, which keeps the timelines tidy, and then we use additional kanbans and/or dashboards to roll everything up, depending on PM preferences.

I use a variety of different tricks to create those recurring issues via automation, too - some are triggered by activities in Jira, others are on a schedule, etc.

[Kit]

We do this, too. 

I maintain separate projects for support-related work, so it doesn't get tied up in sprints / reporting for development work. 

[Mathew Lederman]

It sounds to me like you could use one more IssueType, 'Support Requests', on the same level as Epics in your hierarchy. I would suggest time-boxing these Support Requests to prevent things going forever unchecked. Even something as simple as "Create new job in Oracle for Technician Q1" and then closing it out at the end of the quarter.

Alternatively you could create an Issue Type for each Support Request, which may alleviate the need for the epic. This could get messy quickly depending on how many types of support requests you receive.

[Anne Saunders]

Our Support issue type is at the basic issue (Story, Task, Bug) level, but it is helpful.

I would lean more toward the quarterly "everything support" epic with these kinds of issues in it.

[Rodolfo Romero - Adaptavist]

"Components" is the legacy, simplest and traditional way of grouping similar requests. Components also have a feature that allows to automatically assign the tickets to a specific person based on the associated component. Some use cases don't require this but it's great having it.

As other mentioned, you can also use "Services", or a custom field created for this purpose.

[Anne Saunders]

My only complaint about components is they aren't automatically inherited by child issues. If an Epic or Story is in a component, all of its children should be, too, right? Using automations to force inheritance would get expensive if we used components across our products.

[Symantha Gates]

Similar to other suggestions made, I recommend a year long initiative (if you use that data type) with four child epics (one epic per quarter) for the operational work and then assign the support requests to the quarter they come in. For example, Initiative = 2025 Operational Support, start date 1/1, end date 12/31; Epic 1 = 2025 Q1 Operational Support ( start 1/1 end 3/31).

Working this way, you have an easy to produce metric - at the end of each quarter you can report on how many support requests were handled (total # of items under the epic). It also helps with resource planning because if there are some bad releases and the support requests trend upward after a bad release, you have more information to push back on the product teams regarding quality of release, training, documentation, etc. You can also show management that your team is not able to spend 100% of their time on projects because * % of their time is spent on operational support. Sometimes these finer points about where time goes are super useful conversations to have. 

If an issue rolls over from one quarter to the next, you and your team get to decide the ground rules of how that will move ahead or if it will be duplicated. Add those to your Confluence page or other documentation where you articulate how the team works. You could also use a label = unplanned on all the stories/tasks under the operational epics if you like to separate planned vs unplanned activities, projects typically being planned and ops support unplanned, and do some JQL based on the label. 

[bmccarthy]

We also create quarterly Epics for things like this.  Epic is closed at the end of a quarter and a new Epic is created.   Works quite well.  Also easy to go back and look at your support work for the quarter.  

[Keith Jones]

We use releases (Fix Version) to group things that are time-boxed - typically production support releases. Especially for dissimilar items that need to be grouped by month. or quarter. 

[Evan Prince]

Hi @Stephanie Dietrich , are you using both Jira Software and Jira Service Management to track your work? 

If you are not, I would front all of your support requests with a JSM Portal and manage them there. Support requests really do not fall under Epics.

Also, if your Epics seems to go on indefinitely, I would suggest revisiting your Epics and refining them, as they are likely too vague. Think about SMART goals when you write your Epics:

Specific
Measurable
Achievable
Relevant
Time-Bound

Or tie them to specific OKRs and/or KPIs. Let me know if this helps. Thank you!