I would like to be able to have an Epic ticket associated with a top level item (Initiative), without having a second tier container ticket (Milestone) in the middle.
Using advanced roadmaps, we've configured a multi-level hierarchy to allow for epics to be contained in milestones, and milestones to be contained in epics.
The roadmap settings interface shown above allows me to associate multiple ticket types with each level in the hierarchy, but a given ticket type can only be associated with a single level. So with Epics as level 3, they are not available to select as level 2. And with Milestones as level 2, they aren't available at level 1.
I've also tested having one type at level 1 (type A) and two ticket types at level 2 (B & C). In that scenario, a level 2 type of ticket (B or C) can have a parent link of ticket type A (level 1), but not of either type B or C (level 2).
@Curt Holley the Epic type is fixed in its position, it can't be shifted, as far as I can tell. If you're able to make that change, I would love to know.
Also, the parent-child relationship between milestones and epics is the more common case for us, and where we get value from advanced roadmaps. Losing that is not a win.
@Alex Bernardin True!!!
@Dave Releases suggestion might be worth thinking about. But that may depend on how Releases are being uses across your Projects/teams currently.
have a read of this as a starter on Releases and versions | Jira Software Cloud | Atlassian Documentation
Are you able to give an example and explain a little more on how you use milestones?
Cheers
Mark
@[deleted] recognizing that the word 'milestone' has connotations; for us it's really just meant to be a grouping of work tickets.
A story can be completed in a two week cycle
An Epic consists of a set of stories, and likely will spread over several cycles
A Milestone consists of Epics, and will likely spread over several months
An Initiative might last for 9-12 months, and ideally consists of a combination of Milestones and Epics.
We could have called the ticket type 'bob'. The pain point is that with the strict hierarchical relationship, it means that if I want to have a year long initiative, and include some epic-sized things, and some milestone-sized things, each of the epic-sized things has to have a milestone thing above it - a milestone container with a single epic element.
Thanks for explaining this further, @Alex Bernardin
I'd agree with what @Dave has suggested, which is to consider using releases/versions. Here is some documentation on how this works in Jira Software and Advanced Roadmaps.
Hope this helps.
Cheers
Mark
Hi @Alex Bernardin ,
Have you considered using Releases as an alternative to your milestone hierarchy level? You'd be able to use them at all hierarchy levels and you can also set start and end dates on them.
This might be a good workaround to the problem if you're not currently using releases?
Regards,
Dave
Dave, I have not looked much into Releases. if you have a link handy for a good explanation of the feature, I'm happy to learn about them
It looks like @Mark Davies has provided some good links, but I'd also suggest this as another one as it shows how the releases appear on the Advanced Roadmaps timeline: https://confluence.atlassian.com/jiraportfolioserver/monitoring-releases-967895276.html
I have this same need. Because I have some projects that are very complex, and some that are not. So I need the 5 levels of the hierarchy for some, but if I want the top level for continuity, I have to create a bunch of fluff hierarchy to get to epic level for my smaller projects. It is confusing to people on those smaller projects.