How do I set up a Initiative-Epic relationship in JIRA Software?

[allan.reventhell]

Hello! I'm new to JIRA and could not find a crisp answer to this question. I'm currently running a scrum type project (let me know if this is the wrong setup for my purpose).

I've set up two boards (one for each team), created a set of stories and linked them to Epics. I can clearly see the Epics progress in the left-hand panel of the board.

But how do I integrate Initiatives into this? I think it would be neat to use Initiatives as the building blocks of our roadmap, and it would be nice to see the progress of an Initiative as a function of underlying Epics.

After some googling, it seems I need something called "Porfolio" in order to define hierarchies, but surely JIRA Software should have this sort of capability?

Hope that was clear - and please let me know if you see other ways of achieving this 

Thanks

[Matt]

Hey Allan,

Natively in Jira, the hierarchy is set to Epic -> Standard Issue Type -> Sub-task Issue Type.

The 'Epic' Issue Type will always be at the top, with all other Issue Types being linked up to the Epic via the Epic Link field.

Portfolio for Jira enables two things relevant to your issue; the ability to create custom hierarchies, such as having an initiative Issue Type above an Epic, as well as the 'Parent Link' field, which allows you to link upwards to the next rung up in your custom hierarchy such as linking an Epic to an Initiative. 

Without Portfolio for Jira your best bet may be to create a new 'Initiative' Jira Project with a kanban board and with a new Issue Type named 'Initiative', and use the 'Linked Issues' field on the Epics to link the Epics to the relevant Initiative in the new project. With this you will be able to use JQL to report on the initiative on a dashboard gadget, such as:

issue in linkedIssues(issueKey)

 The above JQL will return all issues that are linked to the issue (specified in 'issueKey).

Additionally, you will be able to see the Epics from the sprint projects linked under the initiative in the new project when you look at the initiative issue in the issue view.

Let me know if you have any questions, or if this solves your issue!

Cheers,

Matt

[Sebastian Mühleis]

Hey @Matt ,

thanks for your reply - I have a question going hand in hand with @allan.reventhell question - and maybe you can provide further insight or even provide a concrete answer to it. We're using Portfolio for Jira and I had no problem implementing/integrating the "new" hierarchy with an initiative at its top.

BUT: This does not translate to Jira Software (Cloud), since initiatives are still a standard task there, which is only linkable to an epic (and not something like "create epic" in an initiative). Do you understand my problem or do I have to elaborate further?

Thanks in advance for your help,

Sebastian

[Sebastian Mühleis]

So basically what I want is: Sub-Tasks roll up to Tasks, Tasks to Epics, Epics to Initiatives. But right now in Jira Software the Initiatives are comparable/treted by the system as if they were "regular" tasks, and thus "inferior" to epics.

[Matt]

Hi @Sebastian Mühleis ,

It's usually best practice (from my perspective) to have a separate Jira Software project entirely for initiative level issues, this is so that they can be tracked independently on a Kanban board, and allows for cross-project linking to one or more Jira Software Scrum or Kanban projects that are focused on delivery (The degree of separation also keeps the delivery projects nice and clean).

Once you have your hierarchy in Portfolio for Jira on Server (or 'Advanced Roadmaps' in Cloud) set up, you will need to include the 'Parent Link' field on the screens for all Epics in all projects (that you wish to link up to the initiatives).  Use the 'Parent Link' field instead of the 'Epic Link' field so that your Epics can be linked to the higher Initiative Issue.

Hopefully this solves your problem. Let me know if you would like me to take the example further, or if this answer is off the mark.

Cheers,

Matt

[Sebastian Mühleis]

Hey @Matt ,

yes and no :-D

I totally understand your approach/idea/input, as well as from the practice level as from the technical level. And I guess/hope the "parent link" field solves the existing problem of the hierarchical setup of initiatives "below" epics. Nevertheless, what we're trying to accomplish is a clearer view of the board regarding the swimlanes. So we'd prefer if the initiative is the highest level, can be expanded to epics, and these then to tasks/subtasks (as we do at the moment with the swimlane view set to epics and - if needed - changed to story).

And what I do not really get from your description of your best practice: What do you do with tasks that influence several epics, which may be connected to different initiatives? How does this translate to your initiative view on a Kanban board (we use Kanban boards - or rather Kanplan boards, with a backlog - as default by the way).

Hopefully you get what I mean - if not let me know and I'll try to describe a little bit more transparent ;-)

And thanks in advance for your help/insights,

Sebastian

[Sebastian Mühleis]

And, in addition: How can I change the swimlane views to "initiative"? Up to now, I haven't been able to do this.

[Matt]

Regarding Scrum or Kanban board swimlanes, it is currently not possible to set a hierarchy based drop down swimlane natively.

What may be useful for you is a marketplace add-on named Structure, which provides the drop down visibility of issues within a separate page.

To answer your question ('What do you do with tasks that influence several epics...'), if you think about the how the work is broken down, usually that particular influencing task is a part of a single Epic, but merely serves as a dependency for the other tasks in the other Epics. 

In Portfolio for Jira, this is marked using the 'Linked Issues' field using the 'Blocked by' link.

Otherwise, if the task truly is connected to multiple Epics (which rarely might be the case), you can choose to place this task into the Epic you wish to complete first during the work breakdown, so that the other Epics are not blocked by the dependency.

Hopefully this helps,

Cheers,

Matt