Project management using multiple JIRA projects

Hello All,

We're about to start using JIRA and need to figure out about how we will deal with project management. To put some context, we're a multidisciplinary engineering team (software/hardware/mechanical) and thus, we will one JIRA project for each different product (e.g. a mobile app, a FPGA core, some mechanical module, etc.). Each of those projects will contain the feature requests, the bugs, etc. That's all fine.

Now, the problem is when we start a new project that would involve several of those JIRA projects. What would be the most efficient way to achieve this?

I read the following Q&A which is basically the same question:, it is 4 years old so I'm wondering if there's now something better than cloning/issue linking?


6 answers

1 accepted

Linking everything to some high level epic/story still makes sense; alternately/additionally, you can create an agile/scrum board for the project and include whatever JIRA project(s) you want on the board.

Thank you.
However, do you think it would sense to create a Scrum/Kanban board even in the context of multidisciplinary teams? I believe it would be more restrictive than creating a separate high level project (with custom workflow, fields) and from which charts (and other PM stuff) could be generated. Thoughts?

Assuming each team already has its own scrum board, then no, I don't think a higher level board makes sense.  Or maybe it does, but only for a higher level scrum meeting.

Likewise, having a project in JIRA that represents the parent epic for a group of stories, where those stories are spread amongst other projects makes sense; in the context of the higher level scrum meeting, you would pull those stories into each individual team's scrum.

As far as a JIRA project for actual managing of the project, I'm not really sure what that would represent.   Possibly a rollup of all scrums?  In a way, that feels like repeating work, but it mostly depends on the scope of the project manager's involvement.  Is this PM managing all scrum teams, or just the multi-disciplinary aspects?  Or, similar but not quite the same, is the PM managing one project, that needs to be scheduled/coordinated with other PMs who are managing the work done by individual teams?

The goal of the higher level project would be for the PM to have a big picture view (pull burndown charts, etc.). Not all groups (e.g. mechanical) are agile, hence why I think creating a scrum board is not necessarily the best choice.

Also, since a global project (including hardware, software, mechanical) may refer to multiple software/hardware/mechanical products, I don't think it would be convenient to have the PM fetch and consolidate from all of them. That's why perhaps the best solutions are either to create higher level projects (primarily for tracking) using clone/linking OR use a plugin that can do cross-project structures like Robert proposed below.

One problem I'm seeing now is time tracking. If I just clone and link inside the higher level project, that doesn't make the time tracking information be transparently copied. Ideally, team members should only have to enter their time in their tasks inside the "product" projects (lower level).

Is there an easy way to address that issue? The high level project should have containers that can link to multiple stories and inherit the time tracking info.


Hi Alexandre,

Luckily in 2016 there are more options that linking issues smile.
What you are describing is a classic Program structure which involved multiple product/team deliverables.

Using Cycle Control add-on you can define your Program/Release as an aggregation of all the JIRA projects. Once this is done you can add stages, milestones, checklists and metrics - basically that help you control the execution and stay on top of it.

Your initiatives can be shows on interactive calendars, all the data is ready for reporting and a lot more features.

It is a great tool designed by PMPs with exactly your case in mind.

if you need a demo or further help drop us an email at

Peter T

Alexandre, you might find our Structure plugin helpful.

It lets you create cross-project structures (hierarchies) of tasks (which you can synchronise with Agile boards) for planning, execution and tracking purposes.

With regard to overview and tracking, you can easily group your Epics into higher levels to track progress, estimates, etc.

None of this interrupts your Agile workflow.

Thank you, I'll keep this in mind. 

The BigPicture plugin for JIRA lets you work in a multi-project manner by introducing Programs. It's fully compatible with JIRA Agile, too:

In the end of the day, you need plugins for evertyhing in Jira. There is always something missing... 

My company is currently evaluating several plug-ins, including Big Picture, Structure,  Jira Portfolio  and Tempo Portfolio to track and visualize progress in a multi-product, multi-team environment.  So far, nothing we've looked at does a decent job of pulling this information together in a way that supports the idea of a common product backlog with multiple teams pulling work to their team backlogs (e.g. boards) while giving an accurate status and forecasted completion dates per-release.

What I am seeking is a Version Report, like the one built into Jira, that can aggregate the work across multiple Jira projects (because fixVersion/Releases are tied to just 1 project).  I've tried many solutions within out-of-the-box Jira but each has downsides that I'd like to avoid.  We were extremely disappointed by Atlassian's own Portfolio product because it *does* enable aggregating work from multiple projects but has no burn-up or burn-down charts to visualize the aggregated data.  :-(

Anyone else solve this problem?

In the meantime, I've requested an evaluation of Cycle Control which has some burn-up/down capabilities.

Hi Joel,

Can't speak for other products, but in Structure it's possible to aggregate work across multiple projects. If you have version names synced, you can "group by version name", for example. Another related feature is Excel-like formulas based on issue fields and the work breakdown structure, which can then be used for sorting, grouping and filtering.

However, Structure also lacks burndown charts - sorry! We're planning some charting features and integration with larger charting apps, but for now it could be period export (either manually, to Excel, or programmatically via the API).

I understand it might not be exactly what you need but I wanted to mention some features since you mentioned Structure. Feel free to write us at if you need a more detailed advice.



Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,865 views 12 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot