Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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


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.


1 comment

Speaking for, 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. 

Like robert_quinn likes this

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.


Log in or Sign up to comment