nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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!

Comments

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.

Felix Malinis_r1ognn

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.

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.

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.

Symantha Gates_v9yyuq

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.

Maura Swart_r33thc

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.

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.

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.

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.

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.

Kit_ezjx5s

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.

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!

Josh McManus

This is what I'm currently suggesting to some of my teams. They regularly get into priority conflicts between CS priorities and PM priorities and it usually leads to the engineering team feeling pulled on. I'm suggesting they move to an "on-call" model where engineers rotate through the "support queue" where they don't contribute to team velocity but instead they focus on CS bugs and engineering priorities. It keeps the priority lists separate and dedicates some engineering capacity to CS while keeping product capacity stable. I'm hopeful it's a suggestion they're able to be successful with as I've seen it work in other organizations. Another good use case for this multi-track model is to use that carved off time to do advance Proof of Concepts and investigations to improve planning estimates and designs.

Welcome!

It looks like you're new here. Sign in or register to get started.