Our team has been working with JIRA for issue tracking for about two years now. We keep running into the same problem over and over again.
We have several shared libraries and components that get used across different products. The issue is that JIRA treats each project separately. This works okay when you think about it from a customer perspective, but it becomes really messy for developers who need to work on the backend stuff.
The built-in components feature in JIRA just doesn’t cut it for what we need. When a developer is working on a shared library, they can’t easily see all the related issues from different projects or track which version of their library each issue affects.
What we really need is some kind of project hierarchy. Like having product-level projects that can connect to module-level projects underneath them.
I know Atlassian has been asked about this feature many times but they haven’t added it yet. Switching to a different tool isn’t really an option for us right now.
Right now I’m thinking about using components in the main projects and then automatically creating linked copies of issues in the library projects. This isn’t perfect because the connections aren’t as strong as I’d like, and it creates duplicate issues everywhere.
Has anyone else dealt with this kind of setup? What solutions have worked for you?
honestly we just started using portfolio for jira and it kinda solves this. you can group projects under initiatives and get that cross-project view your looking for. bit pricey tho and takes some setup but way cleaner than all the linking workarounds we used before
We faced a similar challenge when managing our microservices architecture across multiple client projects. Instead of duplicating issues, we ended up creating a dedicated ‘Shared Components’ project that serves as the source of truth. When an issue affects a shared component, we create the main issue there and use JIRA’s issue linking to connect it to the affected product projects. This approach requires some discipline from the team, but it eliminates the duplicate issue problem you mentioned. We also use custom fields to track which product versions are impacted, making it easier to see the full scope of any component changes. The key is training your team to always check the shared components project first before creating new issues.
After dealing with this exact problem for three years, I found that using epics as cross-project containers works better than trying to force component hierarchies. We create umbrella epics in our main integration project and link all related stories from different product projects underneath them. The epic becomes your single view across all projects for that shared component work. The trick is setting up automation rules that automatically link issues when certain component labels are added. This way developers don’t forget to create the connections manually. We also run weekly reports using JQL queries that search across all projects for specific component labels - gives us the visibility we need without restructuring everything. It’s not perfect but avoids the duplicate issue mess and keeps stakeholders happy since they still see their product-specific backlogs normally.