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

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

Avatar

1 badge earned

Collect

Participate in fun challenges

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

Challenges
Coins

Gift kudos to your peers

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

Recognition
Ribbon

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!

Leaderboard

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
4,555,354
Community Members
 
Community Events
184
Community Groups

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

Edited

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 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. 

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.

Comment

Log in or Sign up to comment