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).
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?
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
@Mark 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.
To do this you will have to either flatten the hierarchy (as you have described) and have Milestone and Epic share level two. This would mean any linking of any issue types at the same level (Milestone, Epic in this case) would need to be linked via a link type and not a hierarchical style link like Parent or Epic link.
Alternatively you could consider moving Milestone to level 3, but then you would have the same issue with milestone that you currently have with Epic.
I would go with them both at level 2 and possibly create a custom link type for milestone to Epic (and vice versa), if need be???
@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
We know that great teams require amazing project management chops. It's no surprise that great teams who use Jira have strong project managers, effective workflows, and secrets that bring planning ...