Best Practice for Using Initiatives & Phases in Jira Premium Plans?

[cvanduyn]

Hi Everyone,

We’re setting up a new program in a mostly greenfield Jira Premium Cloud instance, and we plan to use Plans for our roadmap. Because of this, we’ll be working with the Initiative issue type.

Our program has delivery expectations tied to defined Phases, and we’re trying to determine the cleanest and most scalable structure for representing those phases in Jira.

We’re considering two approaches:

Option 1: Single Initiative + Custom “Phase” Field

Have one Initiative for the entire program, and use a custom field called Phase.

We would then require either the base-level issues or Epics to have this field populated (with a workflow validator enforcing it). This keeps everything under one Initiative but relies heavily on correct field usage.

Option 2: Multiple Initiatives (One per Phase)

Create separate Initiatives such as Phase 1, Phase 2, Phase 3, etc. This makes each phase its own parent container but means we’ll end up with multiple Initiatives for what is essentially one program.

---

Has anyone implemented something similar, and which approach worked best for you?

Are there any pros/cons we should be aware of in terms of reporting, plan visibility, or long-term maintainability?

Thanks!

[Tomislav Tobijas · Accepted solution]

Hi @cvanduyn ,

Have you considered using two different work types? Meaning, one for Initiative and another for Phase?

We did exact approach for one implementation (the names of work types are just different) and the process is fully supported.

What you can also find in Atlassian demo sites is the following structure/hierarchy.

It's quite generic, but it should support a lot of cases.

In the end, it all depends on how your organization and processes are constructed and what you want to achieve, but I agree that both options you've presented have their pros and cons.
If I had to choose between the two, I would rather go with option #2 as it's technically 'cleaner' and might have lower risk than the first one 👀

Hope this helps.

Cheers,
Tobi

[cvanduyn]

Thanks for the amazing response @Tomislav Tobijas 

Are you suggesting that Atlassian is informally supporting the use of a "four-position" hierarchy (base-level, epic, project/feature, initiative) in their demo site?

In our Jira premium cloud instance, the default work item hierarchy is "three-position" (base-level, epic, initiative).

When adding additional items to the work item hierarchy, like introducing Project/Feature, we noticed that this change had a global impact, requiring all other projects in our Jira app to include the new work item to maintain a parent-child roll up to the initiative.

Or in other words, we could not create a custom project/space-specific hierarchy. We could only modify the work item hierarchy globally, affecting other projects/spaces.

Because modifying the work item hierarchy in Jira affects all projects/spaces globally, we prefer a project/space level customization.

Paying for an additional Jira premium app/site within our Atlassian org for a custom hierarchy that applies to just one project/space is not something that I can get approved.

With this additional context, do you have any thoughts? Otherwise I'll gladly accept your answer above. Thank you again so much for your help.

[Tomislav Tobijas]

Hey @cvanduyn ,

Are you suggesting that Atlassian is informally supporting the use of a "four-position" hierarchy (base-level, epic, project/feature, initiative) in their demo site?

I'd say so. You would need to dig this out a bit (I don't have an actual reference), but you could check sources like Success Central or Atlassian Learning. I might have seen this example somewhere out there.

I mean, in the end, you can configure it however you like - 3 levels, 4 levels... It goes up to 25 levels (that's the max) - I've only played around with it, but never seen anyone using more than Epic > Deliverable/Legend > Initiative/Project 😅

...requiring all other projects in our Jira app to include the new work item to maintain a parent-child roll up to the initiative...

Hierarchy is global, yes, but you don't need to add Initiative to all projects. Some projects could have initiatives, others not. Also, parent-child relations are not limited to a project (now called a space); excluding Sub-tasks > they need to be in the same space as the parent.
👉 Meaning, you could have Initiative in one project, and Epics in another.
Here's one example > you could implement it in a way that only one space contains Initiatives, and all others would contain Epics, Stories..., where Epics would use parent-child relations to connect with those Initiatives.
Below is an example of how we implemented one solution 👀

• One main space containing Initiatives (and one level below)
• Every other space contains 'standard' work types

Again, it depends on what the process is, what the requirements are, and so on, but you could probably support most use cases.

Also, there is a feature request for having separate hierarchies on a space basis: JRACLOUD-93859: Have the ability to change issue hierarchy per Project but I doubt this will be implemented any time soon.

An additional note, you could explore Atlassian Home and home projects, but these are relatively limited at the moment. However, some additional features are in the works when it comes to this.

Hope this helps.

Cheers,
Tobi