Hey all,

Thank you for sharing you feedback about hierarchy configuration. Oeer the past couple of years the team has worked on making Hierarchy a deeper core function across native Jira, not just Advanced Roadmaps.

However we want to be open about the fact that we don't intend to make changes in the way that Hierarchy is configured based on custom issue types. Therefore this ticket will be closed as 'Won't Do'.

Kind regards,

Rhys | PM Jira Plans Cloud

I don't believe the title, description, or perspective of this Suggestion Issue is a valid or cogent representation of the consequences of the way the Roadmap team elected to implement a structure for managing the grouping of semi-hierarchical objects to represent the reality of Programs overseeing Portfolios overseeing Initiatives overseeing Epics overseeing Stories/etc. overseeing sub-tasks.

The current implementation of 'Roadmap' (a routing terminology) is not a functional routing mechanism, but a primitive re-application of the object-design structure of the Project sub-hierarchies of Epics, Stories, and Sub-tasks re-purposed to extend the hierarchy upwards, but certainly not outwards. And the meaning of routing is certainly three-dimensional and topological, whereas hierarchies are abstract directed networks traversed by rigidly constrained algorithms.

The appropriate concept must apply, and then the structure can be imagined.

The existing Project hierarchy consists of more than just the support for the hierarchy itself, several other structures and relationships exist and are supported by code that manages the underlying XML object representations. Sprints, backlogs, workflows, versions, boards, each have supporting integrations that become aware and participate during the project lifetime. The code that is aware of those states and reacts appropriately to produce meaningful results which are recognizable as 'development management' become the code-bound restrictions that interfere with new designs and features. And that's appropriate, because that's how code works.

The existing 'Portfolio' functionality 'poops out' when it comes to the basic agile project feature set: Sprints, versions, releases, backlogs and their related operations. So we have 'cross-project release elements' and similar ancillary data elements which have Project-level impact, but no Portfolio or Program functionality.

Thus we have the reduced-functionality of the Initiative, a rudimentary way to re-use the existing functionality of the Project feature-set to extend a super-structure up into the portfolio and program concepts. Its like building a group of apartments on top of a sports arena. They have no foundation and no operational support.

And the alternative, using the Project's Issue-minting logic, which makes sense in the abstract world of XML structures and super-structures, simply fails to produce any super-hierarchical object at all since the Initiative Issue-type has no existence or integration with the (limited) support features provided by the Roadmap. It provides only the value of an object 'named Inititiative' at the Project level, and nothing outside the project can really depend on it or utilizes it for useful Program or Portfolio operations.

There really is no alternative to building a parallel universe of XML structures and XML manipulating components at the Program and Portfolio levels. And those components need to manage the representations of Projects, Issues, Versions, Sprints, Estimates, Backlogs, and all the other Project-based structures at the upper layers. and the operations needed at that level involves a new set of abstractions, features, paradigms and realities.

Thanks,

Kimball Johnson