Suggestions for organizing Epics and Bugs for O&M

[Marti Morano]

What is the best way to organize Epics and Bugs/Enhancements) in Jira for an O&M shop?

Do I create an Epic called something like PRODUCTION ISSUES then create issues (Bugs and Enhancements) under that Epic?

Or maybe create an Epic for each quarter of the year so that the Epics don’t stay open forever? You could then close the Epics at the end of each quarter. Call the Epics something like PRODUCTION ISSUES 2025-Q1, PRODUCTION ISSUES 2025-Q2, etc.

• Any other ideas? Please help. 

[Atlass Monster]

Do a test run with both of your ideas. You can't know what will end being the best for your team unless you have an experience with that work set up.

[Marti Morano]

Thanks. That was helpful. We do Epics with logical/ functional categories for new dev. It’s O&M that’s giving us a challenge. If, say, we have one Epic per quarter for O&M, as suggested. Can you have one bug in a release? I understand doing that for a Hot Fix but would f it’s not urgent, collect a few bugs for release together. Right? If we we mix O&M  and new dev in one Epi/bucket, I guess you can tell where the new dev is based on the release?

[Atlass Monster]

Sure, have as many Bugs per Epic/Releases. You don't exactly do a standard things here, so maybe (as only suggestion) consider going a step back and look it at as a big picture. Can you simplify something? What else down the line can cause problems or raise more questions (thus slowing you down)?

[Walter Buggenhout]

Hi @Marti Morano and welcome to the Community!

There is no silver bullet answer to your question, to be honest. It all comes down a lot to how you (or your teams) manage and organise your work.

Just as a thought, I have a personal preference to use epics for more meaningful categorisation of work than just by time or environment. Let's assume your shop consists of a couple of functional modules, it might make sense to have an epic for e.g. the online portal and one for the payment system. You can use versions (releases) to deal with the time aspect and the environment custom field to indicate where issues were found.

I do understand that it makes sense to close your epics after a while. And from that perspective, doing this per quarter or per year might be a sensible approach, to some extent depending on how many issues you process over time.

Hope this helps!

[Walter Buggenhout]

If, say, we have one Epic per quarter for O&M, as suggested. Can you have one bug in a release? I understand doing that for a Hot Fix but would f it’s not urgent, collect a few bugs for release together. Right? If we we mix O&M  and new dev in one Epi/bucket, I guess you can tell where the new dev is based on the release?

Yes, of course. Epics and releases are separate concepts. You don't need epics to add issues (of any type) to a release. And a (standard) issue type can only be linked to one parent epic, but to multiple versions, if that might ever become a need.