How can I add a tier to the issue hierarchy?

[Martin Freeman]

In Jira I have:  Epic -> Story -> Subtask.

Our project is structured along the lines:  Feature -> Epic -> Story -> Subtask.

How can I model this in such a way that different Features still coexist on the same project backlog and Epics and Stories on the backlog can be organised and filtered by the Feature?

I don't see anything in Jira itself that enables this.

I've looked at Structure and it appears that using that I can create a Feature structure above Epic, but the documentation suggests that additional Feature tier only exists within the Structure plugin itself and so cannot be used to organise and filter the backlog. Which if that's the case doesn't seem very useful.

This Atlassian Agile coaching article Epics, Stories, Themes and Initiatives  even describes exactly what is needed but gives no details on how to actually achieve it. It says stuff like:

Internally, we call our Initiatives “PC Tickets.” Project Central tickets are configured in Jira Software just like our epics.

and

Initiatives are collections of epics

...which implies that Epics somehow can contain other Epics. But the link in that article to Jira Epics Tutorial makes it clear that this is not possible.

Does anyone know how of a way to do this?

[Nic Brough -Adaptavist-]

Your findings are correct 

The "Atlassian Agile coaching" article is a little misleading as it doesn't explain that their upper level alongside Epic is simply another type of story-level issue with some links and reporting that replicate some of the Epic functionality.

That's broadly what Structure does too - its layers of hierarchy are an adjunct, a layer over the top of epic/story/sub-task and also works differently.  The core of Jira Software and Service Desk still sees those issues as Stories.

However, Advanced Roadmaps (nee Portfolio) does implement themes and initiatives, which can be used as features, and if you're large and are thinking of scaled Agile, Jira Align may be worth a look.

[Egor Tasa [ALM Works]]

Hi Martin,

Let me add a couple of cents here. Indeed Structure can visualize any kind of hierarchy, even the one not present in Jira. Though if you use issue links, you at first build the hierarchy of arbitrary complexity in Jira and then reflect it in Structure. And what is important, you can use Structure to manage backlog or use Structured JQL to populate boards and filter. Not everything is possible this way, but it is possible your use case can be covered by Structure.

Regards,
Egor Tasa

ALM Works

[Martin Freeman]

What do mean by "build the hierarchy of arbitrary complexity in Jira", it seems pretty clear that this is not in fact possible in Jira. You have Epics->Stories->Subtasks and that's it.

Assuming what you say is correct and that this is possible in Structure is there any information anywhere on how I would go about that? I've looked through the Structure documentation and not seen anything that looks applicable.

If the answer is simply 'look harder' I'll dig into it some more because I have in honesty only skimmed the docs :)

[Egor Tasa [ALM Works]]

Hi Martin,

Using links like "depends on" or "blocks/blocked by" you can build any kind of hierarchy. Though such hierarchy does not necessarily affect any functionality in Jira, it is possible to build it, and Structure (and some other plugins) is a way to visualize it and calculate different metrics, manipulate and plan. You can check our sandbox for this, here is a good example of such hierarchy: https://jira.demo.almworks.com/secure/StructureBoard.jspa?os_username=demo&os_password=demo&s=152#

If you are interested in more in-depth demo of Structure, you can contact us at support@almworks.com

Regards,
Egor

[Martin Freeman]

That's very interesting. I'll have a look into that in some more depth.

Thanks.

[Dave Rosenlund _Trundl_]

Hi, Martin.  To add to what Egor & Nick said, by my calculations there are easily more than 30 thousand active Jira installations that use a Jira app (Structure, Advanced Roadmaps, Jira Align, BigPicture, etc.) to extend the out-of-the box Jira hierarchy as Egor describes.

It may not be codified in the Jira code base, but clearly many organizations depend upon this ability to extend the Jira hierarchy is some way shape or form.

Moreover, each of these products do much more than enable you to extend the Jira hierarchy. That's just one of the things they can do. Egor eludes to this, too.

Think of Jira as a platform, that can be extended in all sorts of ways to meet your specific needs.  

That is the beauty of the Atlassian Marketplace, IMO. (And the foresight of Atlassian to realize their products would deliver even more value to their customers if there were an active ecosystem surrounding them.) 

-dave [ALM Works]

[Jeff Close]

@Dave Rosenlund _Trundl_ I've used Structure and I like the product a lot.  It provides some useful features.  However, I think that you are overselling the capabilities of add-ons in general in JIRA, and I think that it is a stretch to call JIRA a "platform".  Many of the add-ons (well, I think pretty much every one I have used, including Structure), provide additional functionality through adding custom fields or by having the user create their own relationships between elements through things like Issue Links.  Most of the actual added functionality comes in the form of a new UI for viewing these relationships. 

For example, Structure essentially gives you one more screen presentation that shows a different collection of information (ignoring config screens and the dialogs which are just management).  If you have defined an additional layer of hierarchy through defining a new Issue Link, this can be viewed in this screen presentation.  That's a nice feature. 

However, the problem with all of these is that core JIRA does not know anything about these additional fields or relations, and most JIRA features do not reflect whatever changes were made.  For example, one can add all the additional hierarchy they want, but all the standard JIRA Sprint reports will not show this hierarchy; the core Epic-Story-Subtask hierarchy is still "baked in" to JIRA in very fundamental ways.  In that sense, if you want to view JIRA as a "platform", it is akin to an SDK in which you're having to derive from some base classes that have frozen in some functionality through inheritance.  They did not generalize the concept of "hierarchy" in their "platform", so as far as I can tell, there's nothing that you can do to escape the inherent core design.  Rather than giving Atlassian credit for their vision, I would say that they made some fundamental errors in architecture design which they now either can't or won't change, and are relying on plugins to try to make up the difference.

[Dave Rosenlund _Trundl_]

Hi, @Jeff Close.   Thanks for adding your thoughts to this thread.

You make some very good points and I agree with most of them. We may disagree about whether or not Atlassian made fundamental errors in architecture and design — but I still respect your opinion.  :)

I guess I take the view that if you are going to use (or have to use) Jira, you have to embrace it as it is and as Atlassian says it will be (in their cloud & data center roadmaps), advocate for changes (as you are here, today), then go from there. 

Best,

-dave