How do ALM Works Structure and JIRA Agile fit together?

[Thomas Keller]

So I recently played around with ALM Works' Structure plugin and think that it could be used to organize the business perspective of our backlogs quite well. What struck me though was how product owners could effectivly use it to plan sprints with it.

As I see it there is a bi-directional JIRA Agile synchronizer that syncs - among other things - the rank field and epics, but surely this is not sufficient to keep a proper overview. Imagine you have a deep structure of epics and sub-epics, where you group different functionality until you finally reach the Story level. Now a PO naturally wants to pick certain of these stories and pull them into a Sprint, but how can he do so effectively?

JIRA Agile's planning board shows all epics created in Structure as a flat list (that is not even filterable, but yeah, JIRA Agile's fault) and there is no other view - to my knowledge - where I could pull individual stuff from the structure to the sprint.

Are there any best practices I'm missing here? Do I have to create an artificial "Sprint" epic in Structure and pull stuff from other epics into that to have it somehow grouped nicely in the planning board? That would, however, defeat the whole purpose of having a structure in first place, because I'd effectivly destroy it with such a workaround.

Of course, if you know of an alternative to ALM Works solution, I'm happy about any pointers there as well  Thanks for your answers!

[Frank Schophuizen]

If you are dealing with Epic-Epic relationships (links) and Epic-Story relationships (Agile), you probably need 2 synchronizers:

• Agile synchronizer
• Links synchronizer (for example looking at implements/implemented links)

Be careful with this combination! You may get all kinds of unexpected effects!

For example:

Let's assume you have Epic1, Epic 2 and Story 3. On your Scrum plan board you associate Story 3 with Epic 1, which sets the 'Epic link' field in Story 3. In the structure the Agile synchronizer puts Story 3 under Epic 1. Now the Links synchronizer kicks in to create an 'implements' link from Story 3 to Epic 1.

Now, someone else looking at Story 3 sees the 'implements' link to Epic 1 and wonders why: there is already an 'Epic link' to Epic 1. So he removes the 'implements' link. Then the Link synchronizer puts Story 3 at the top of the hierarchy. And then the Agile synchronizer kicks in to remove the 'Epic link'.

Another example:

Suppose you want to create 2 links (of the same link type):

Epic 1 -> Epic 2
Epic 4 -> Epic 2

Creating the Epic 1 -> Epic 2 will put Epic 2 under Epic 1 in the structure through the Links synchronizer. Adding Epic 4 -> Epic 2 link will move Epic 2 from Epic 1 to Epic 4 in the structure. So the Links synchronizer will remove the Epic 1 -> Epic 2 link.

Result: an issue cannot contain 2 links of the same type

Example 3:

Epic 1 -> issue 5 -> Story 3

The Agile and Link synchronizers will create an 'Epic link' between Story 3 and Epic 1 (in spite of the issue 5 in between) and a 'implement' link between Story 3 and issue 5, and between issue 5 and Epic 1.

[Robert Leitch [ALM Works]]

Excellent examples illustrating the depth of understanding required to make the Links and Agile synchronizer work together in harmony. We strongly recommend *not* mixing the Links and Agile synchronizers. If you absolutely need to mix them, limit the Links synchronizer's scope if possible and plan carefully how the synchronizers will interact. Test thoroughly in a safe environment. There is nothing unpredictable about their behaviour; they follow strict rules. But those rules are complex and also depend on configuration defined by the user. By mixing these two synchronizers together that complexity is compounded, and it becomes more difficult to figure out exactly what will happen in all possible cases. For this reason, testing in a safe environment is very, very important, as is limiting access to create synchronizers (https://wiki.almworks.com/display/structure/Changing+Permission+to+Manage+Synchronizers).

[Robert Leitch [ALM Works]]

Hi Thomas!

You can add the Sprint column to the structure board, and then use it to add issues to sprints (by editing the Sprint field inline in the structure board and setting the field value to the sprint name).

You can do that in any structure; it doesn't even need to be Agile-synchronized, so you could have a backlog structure containing only stories, where you would assign them to sprints (just an example).

Hope that helps,

Robert

Edit - screenshot for comment below:

image2015-6-15 13:31:50.png

[Thomas Keller]

Sounds like a reasonable workaround. Is there anything planned that would somehow deeper integrate the structure tree into the agile views?

[Robert Leitch [ALM Works]]

We don't have any plans to modify the JIRA Agile interface. There is a Structure widget in the issue details panel (I'll add a screenshot to my answer above) which can show you where an issue is relative to the overall hierarchy, but I realise this is probably not quite what you have in mind. Regarding sprints - in Structure 3.0 (major new release, currently in development) it will be possible to generate a grouped structure hierarchy from a JQL query. It will let you create, for example, a structure of issues grouped by sprint, and you will be able to move issues from one sprint to another by dragging and dropping them in the appropriate group.