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; } } }

Project management using multiple JIRA projects

Alexandre Loiseau

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: https://answers.atlassian.com/questions/45858However, it is 4 years old so I'm wondering if there's now something better than cloning/issue linking?

Thanks!

Accepted answers

Jeremy Gaudet

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.

All comments

Jeremy Gaudet

Alexandre Loiseau

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?

Jeremy Gaudet

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?

Robert Leitch [ALM Works]

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.

Alexandre Loiseau

Thank you, I'll keep this in mind.

Alexandre Loiseau

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.

Thanks!

Matthew Jagiell1

The BigPicture plugin for JIRA lets you work in a multi-project manner by introducing Programs. It's fully compatible with JIRA Agile, too: https://marketplace.atlassian.com/plugins/eu.softwareplant.bigpicture/server/overview

Peter T

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 sales@botronsoft.com.

Cheers,
Peter T

danielpoft

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

Joel Robinson_iyr744

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.

Igor Sereda [ALM Works]

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 support@almworks.com if you need a more detailed advice.

Thanks!

Igor

Mumtaz Ahmad

I do have some php scripts that can organize jira task, based on filter in an Agile Gantt Chart which is updated on worklogs giving you a good estimate of finish dates. I will open source them in few weeks. Contact me if you need a demo. Solution is hosted on external server Mumtaz_Ahmad@mentor.com

Amine-Rouh

Hi Joel,

I have exactly the same need as you have described above, Did you find or know anything you can share regarding that ?

An out-of-the-box solution for a Version Report that sums up the work across multiple JIRA projects (based on the Fix/release version).

Thank you

Amine

Greg_oo6oy6

At the moment in Jira the only way to generate burnup/down charts is to use the version report. This is very limiting. Structure creates progress bars at hierarchy points in its UI which is great, it would be even better to be able to expand these into proper burndowns. Cmon Almworks!

Azani Sidharta_w3vbuw

Indeed, business as usual

Birte Rommeswinkel

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software

jira-administration

best-practice

project-management