Hi,

This would be very appreciated to handle SAFe hierarchy, which is Epic > Capability > Feature > US or sometimes Epic > Feature > US

SAFe is one of the industry standards, and it's a shame such a big tool as Jira can't handle it.

Regards,

Is it possible to review this ticket please, and make it progress or not ?

In the Team Managed project we want a hierarchy to be Theme > Epic > Feature > Story > Task > Subtask

Proper parent child relationships between Epic > Feature > User Story > Task

Please please implement this soon.  its rather ridculus its not supported.  

Just reading Haddon's post above and agree with the principles although for me I would drop Issue Types completely as they are now and just have work items. 

These work items can be parents or children of other work items.  Just need a bit of code to stop a work item having the same parent and child.  

The work item would have the minimum basic fields like summary and id plus a "type" that type then adds the relevant extra fields to the view and people should be able to add additional types.  

There are lots of solutions here but having a flat 2 sort of 3 tiered system if you include sub-tasks is a sever llimitation of Jira right now.

I can see tiny pieces of this coming (Advanced Roadmaps being the prime example) but we need more of this, and a heck of a lot sooner. As more and more organizations are "leveling up" to SAFe and other scaled Agile practices (and the more you market Jira as the solution to tooling for these methodologies) the limitations of a flat link are obvious and restrictive.

• We should be able to define layers in a hierarchy and map one or more issuetypes to each layer.
• It should support at least 5 levels ("Initiative -> Capability -> Feature -> User Story -> Task") but ideally it should be customizable. Some organizations are not ready or do not need that many layers; some will find ways to need more.
• We need the ability to query\search on these relationships using JQL including "parent of", "child of", "all descendents of" and "all antecedents of". These will be absolutely necessary for basic reporting, not to mention anything fancier.  It's extremely frustrating for customers to find out they need multiple add-ons to realize a goal they thought they got out-of-the-box, so please don't forget this piece.

Finally, and in my personal opinion only, would be to treat issues in a hierarchy like normal issues and NOT sub-tasks when it comes to UI. The UI\UX of working with sub-tasks in some places is not friendly, and many teams choose not to use them rather than deal with how they look and function on Agile boards.

To be honest, I wouldn't care how these things are called (epics, themes, features, stories, …) as long as they're allowed to be nested. An epic is just a plain user story – only that it's too big to fit a single iteration. You keep splitting these items into smaller ones until you have items that can be implemented in a sprint.

Often it is not even clear when you write down an item, whether it will be an epic or a story. What it is depends on the estimation of the team and their velocity. So simply call these things whatever you like (even the neutral "backlog item" might work), but allow them to be used in an agile manner.

To illustrate, here is how many agile product developments work: 

1. Start with ONE backlog item (you might call it "epic") that describes your product vision and customer/business benefit in the format of a user story (or any other suitable format).
2. Ask your team, ART or company whether this backlog item can be implemented in a single iteration. Most likely they'll ask a few questions and briefly say "no"
3. Split the backlog item into sensible parts (i.e. parts that deliver business value in itself). You might as well call these "epics".
4. Ask the team/ART/company for each item, whether that would fit an iteration. You will likely receive more clarifying questions and a "no" or a "yes"
5. As long as you receive a "no", continue splitting. Once you receive a "yes", call that backlog item a "user story" and implement it.

Epics are NOT categories, feature containers or some other arbitrary grouping. Epics are items that deliver business value and have acceptance criteria to asses when they're done. If we need grouping, we can use other terms (tags, groups, categories, …). Please only apply the term "epic" to things that really are epics.

I would agree with the earlier comment that any company implementing SAFE really needs to ability to have Issue types that match the naming convention. When we train people of SAFE Agile Framework we have to explain that Jira does not follow the methodology and naming convention. We really need the ability to have the standard SAFE Issue types and Hierarchies. 

Both Portfolio and Structure are handy to implement deep issue hierarchies, but in our experience Structure felt more flexible and more practical. It may be different in yours.

Both have basic features to aggregate values along the hierarchy items, but if you need something more powerful, then the Better Excel Exporter app integrates with Portfolio and integrates with Structure. It allows using all the Excel functionality on all the levels.

In our organization the requirement is to have Theme, Epic and Feature levels above the Stories - so we would use ability to configure custom issuetypes on two more levels, one above and one below Epic. We would use them in related custom field (Story screens would have "Feature link" custom field, Feature screens would have the vanilla "Epic link" field, then Epic would have "Theme link" custom field").

If this is implemented, I really believe that the names and features of the additional layers should be customizable in form of custom issutypes - as requested for Epic-like custom issuetypes in JSWSERVER-7203.

Hello all!

Take a look @ Ability to create a hierarchy of Epics instead - my one.pdf... 

Can it solve the problem to rename the Epic to say, Features?  I can see a similarity solution on this problem.

I also think, it can be nice to be able to have more then one issuetype on the same level in the hierarchy.

In the animals.html, you can try to replace/rename the "COW" to be a "BULL", and look what happens.

BR

Lars