Is is possible to use structure synchronizer in an "incremental" way?

[Marcel Sommer]

Hello,

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:

Epic1

Epic2

Feature1.1

  Sub-Feature1.1.1

  Sub-Feature1.1.2

Feature1.2

  Sub-Feature1.2.1

but I need:

Epic1

  Feature1.1

    Sub-Feature1.1.1

    Sub-Feature1.1.2

  Feature1.2

    Sub-Feature1.2.1

Epic2

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

[Marcel Sommer · Accepted solution]

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.

Cheers, Marcel

[Eugene Sokhransky _ALM Works_]

Hello Marcel,

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.

Regards,

Eugene

[Marcel Sommer]

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

[Eugene Sokhransky _ALM Works_]

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 eugene.helpdesk@almworks.com. Please let me know. Eugene