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

Seeking guidance - A Jira Project for each real world "Project'?

Robert Quinn

We are looking at consolidating 4 Jira Software cloud instances - but some groups use a separate Jira Project for each real-world project - and other groups have 1 Project per Program Group/Platform and use either "Component" or "Fix Version" fields to record the name of the "Real-World Project" that issue relates to. This lets everyone work out of their one Platform while doing work across multiple "projects" - also we can relate one issue to multiple "Real-world projects" this way - as some digital development work impact multiple "real-world projects" - since Epic link cannot do that many Epics related on any 1 issue/

What are your thoughts? Do you spin up a separate Jira Project for each real-world effort?

Trying to understand the various Advantages/Disadvantages and possible future repercussions.

Comments

Mike Rink -Seibert Products-

Speaking for draw.io, our Jira project is run more like a "team" project. The larger scale "real-world" projects are planned as Epics, but everything still lives on the same main team project board. This approach keeps everyone together, and I think better reflects our agile reality.

Robert Quinn

Thanks, Mike - appreciate you weighing-in.

That aligns with one camp - and where they need a multi-relationship for Issues - I think Component makes the most sense since an issue can only link to 1 Epic.

I see that natively Components exist in 1 project and Epic-Link spans across - so that makes sense structurally.

Welcome!

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

Quick Links

Find more posts tagged with

jira

project

cloud

jira-cloud

fix-version

component