Just a heads up: On March 24, 2025, starting at 4:30pm CDT / 19:30 UTC, the site will be undergoing scheduled maintenance for a few hours. During this time, the site might be unavailable for a short while. Thanks for your patience.
×Hey there, I’m struggling with setting up our project structure. I use components to cluster the projects topics into some sort of sub-projects.
Below that we have agreed to use initiatives as a highest level deliverable. An initiative must not have any higher or cross dependencies. An initiative can however be relevant for multiple components/sub-projects.
Below initiatives we have epics and below those all kinds of tasks, bugs, features, etc.. Everything below the initiative level has a one to many attribution, meaning an epic can only have one initiative associated to it. An initiative however can have multiple epics. Same is true for epics and the level below those.
So far so simple an straight forward. The problem we get however is that sometimes we have epics that are relevant to multiple initiatives. Those tasks can‘t be initiatives themselves (in our understanding) because they serve a higher level purpose. However they are not just the foundation for a single initiative but for multiple ones. Think about developing IP as a foundation for sending Emails. It’s fine but I also need the foundation of IP for visiting websites.
So it seems like I want many to many attributions for issues. The problem however is that on the other hand, I don’t really want this… I actually need all levels below initiatives to be one to many because I want to be able to make funding decisions based on initiative. Also I want to be able to track, postpone and cancel those without interfering with other initiatives.
TLDR: I need issues types to have a one to many attribution so that I can track, postpone and fund the highest level deliverables individually. However at the same time I struggle with structuring deliverables that serve multiple purposes.
Hi @Sven Fritzsche welcome to the Atlassian Community!
Out of the box, you're doing things correctly but I can see the visibility aspect can be a bit of a challenge. You can do as others suggested such as using issue links.
What I've seen organizations and use in the past was this add-on, it addressed visibility problems for PMOs especially around project resource planning:
Structure by Tempo - Jira Portfolio Management & PPM | Atlassian Marketplace
Please note that I'm not affiliated with Tempo or their add-ons in any way, I just found this add-on quite helpful in various projects I've worked on when it comes to tackling visibility issues.
Hope this helps.
Ash
Hi Sven, Sorry I'm not sure if I get this, wouldn't using issue links (relates to, depends on etc.) help in this? You can extend your levels based on issue links.
Best Regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Sven,
Don't worry. You just need to find a way to structure your projects better that can work for you.
This part of your question really stand out though: "The problem however is that on the other hand, I don’t really want this… I actually need all levels below initiatives to be one to many because I want to be able to make funding decisions based on initiative. Also I want to be able to track, postpone and cancel those without interfering with other initiatives."
I hope this helps. Let me know if something else would help?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Atlassian Government Cloud has achieved FedRAMP Authorization at the Moderate level! Join our webinar to learn how you can accelerate mission success and move work forward faster in cloud, all while ensuring your critical data is secure.
Register Now
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.