I have a three level logical hierarchy using JIRA with the levels "epic", "features" and "sub-features". The first two levels are realized in a JIRA Agile project, so "epics" are realized as Epics, "features" as tasks. The third level is realized in different other JIRA projects, so "sub-features" are tasks in these projects. They are linked to the "features" as child-ofs.
Now I want to have these hierarchy mapped in one structure.
My plan was to use Synchronizers in an "incremental" way.
1) First use a filter synchronizer selecting all "epics"
2) Then use the agile synchronizer to place the "features" beneath
3) Then use the link synchronizer to place "sub-features" beneath
It would be no problem for me to start the Resync manually to avoid side-effects. So I tried to Resync 1): all epics in structure. ok. Then Resync 2) all "features" beneath epics. ok. But when I resync 3) it places all "features" on highest level and the linked "sub-features" beneath.
So I get:
but I need:
So the question: is it possible to "preserve" the current structure and let the link synchronizer only add the linked issues in the structure?
With kind greetings! Marcel
Hi, I have found a solution by myself, sorry for bothering
For all that are interested: It works if one filters the links to be considered by link sychronizer, e.g. Parent issue JQL: project = ... AND issuetype = Feature. Then the issues of type "Epic" are not touched.
Thanks for your question and your answer too . Setting parent/child filters for the Links synchronizer is always a good idea to make sure there is no conflict between different synchronisers.
There is also another idea I wanted to suggest. In our experience it might be easier to manage issues, if you add one level up from Epics rather than add one extra level on the Features level. The thing is that you cannot effectively manage Features and Sub-Features on the Agile board. So instead you could map your desired hierarchy ("epic", "features" and "sub-features") to Initiative - Epic - Story - Sub-Task. This is probably the most frequently used setup. It allows higher-level users to work with initiatives, and create structures for overviews over multiple projects, while developers can actually work in Agile boards if they prefer to and manage their three levels there. If you wish, let me know and we can discuss this in more details in our JIRA or over the email or phone.
Hi Eugene, thanks for your suggestions. Thing here is that the "sub-feature"-level is distributed among different technological groups and this means different JIRA projects / agile boards. And this is also the reason why structure plugin comes into play because it seems to support us the aggregation possibilities we need to manage the project on platform level. But one question to your suggestion: how can I use initiatives? I have not heard about them. And also quick googleing only shows them in relation with other plugins. Cheers, Marcel
Hi Marcel, I'm still not sure I understand how you use sub-features to manage the different tech groups. They still would be under different Epics, won't they? If you have a minute, maybe we can get on the phone and discuss? You can email me directly at email@example.com. Please let me know. Eugene
Hey Atlassian community, I help lead engineering at Sentry, an open-source error-tracking and monitoring tool that integrates with Jira. We started using Jira Software Cloud internally last year, a...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG