I'd like to create a new issue type called Features and allow them to have children types such as EPICs just as EPICs can have many children stories.
Where in Jira is this parent/child relationship defined?
Hi Justin,
Thanks for posting.
As Nic stated, you can't do this with a standalone Jira unfortunately. If you're open to using an add-on, however, I can tell you about our app: Structure for Jira (not yet available for Jira Cloud but that's coming soon).
Structure for Jira helps Atlassian's largest customers visualize, track and manage progress across projects with adaptable, user-defined issue hierarchies. You can definitely accomplish the described hierarchy using its powerful Automation feature, amongst others.
Please let me know if you'd like more information. You can reach our support team at support@almworks.com or you can contact me directly at vlad@almworks.com.
Best Regards,
Vlad
ALM Works
Thank you Vladimir for your answer.
Will your add-on allow a Jira user to create an issue type that can take Epics as children and allow program level backlog refinement to be able to view if desired all the Epics that have been created to show the breakdown of the higher than Epic parent level issue type called say: Feature or Capacility or such?
Thank You,
Justin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Justin!
Sorry for the delayed response.
To clarify, you can create the desired Issue Type(s) in Jira which you can then link to Epics using your preferred Link Type. Structure will allow you to display Epics as children of said Issue Type(s) i.e. "Feature" using our powerful Automation feature, specifically, the Extender Generator.
Structure facilitates working with cross-project teams and therefore allows you to easily visualize such a hierarchy on the Structure Board and any other Jira Page with Structure.
Please let me know if you have any follow up questions.
Best Regards,
Vlad
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Maybe there is a different way to look at this that would change my perspective.
I want to only see Story's in the backlog. I gues ok to see Themes and Epics too. I don't want to see a ton of "Tasks".
I have told my teams to document "just enough" detail and no more to describe the work to implement the Story. This gives lattitude to developers to document in few or many "tasks" to describe their work.
My concern with what I am seeing in JIRA is that I will have Story's and a boat load of tasks in the Backlog. Added misery, at first pass, the tasks don't have any indication of what story they belong to without opening the task.
This will get messy real fast. Some of my developers will tend to over document a task, in example, creating 12 tasks while another would create 5 for the same Story.
Making sense? If you understand what I expect as a Parent-Child relationship, I wouldn't see every task in the backlog, only story's.
What types would I use to accomplish: Story (Parent), Task1(child), Task2(child), ...Taskn(child)?
Thanks in advance.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Brad,
Thanks for posting.
Hopefully I'm not intruding but I just wanted to quickly mention that if you're considering an app to accomplish what you've described, Structure for Jira can help you.
You can create a structure with just your Stories and then if you want, you can use a Linked Issues Extender (or however many you need) to see the Children Tasks on as many levels as you need, in a hierarchy. You can further Group and Filter as needed, essentially having the flexibility to view just what you want and need.
Please feel free to email me directly at vlad@almworks.com or to contact our Support Team at support@almworks if you would like to learn more about Structure for Jira.
Best Regards,
Vlad
ALM Works
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is now possible with Advanced Roadmaps. You can create levels of hierarchy above the epic level.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can you retain parentage through Epic - FEATURE - Story?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, Advanced Roadmaps does Iayers above Epic. Epic -> Story -> Sub-task remains the Jira Software hierarchy beneath there.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You don't, Jira has no functionality to do this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you Nic. I can't believe a product as popular as Jira won't let users create their own issue type to be used at different levels of requirements hierarchy. Most environments have the story level decomposition into tasks pretty well set as a standard.
At Program level however, there seems to be a either a Feature, or an Epic, or Capability all being used to represent a higher level requirement larger than a story.
This would be where a tool like Jira should make the lives of teams and programs easier by allowing customization so be able to track a single user story all the way back up to the source of the initial vision.
What is the best means then for a user in Jira to be able to find the parent of an Epic or create an issue type that will be the parent of an Epic in Jira?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Indeed, I am surprised too that this is just a basic functionality for large programs of work where you need to be able to categorise various issue types for various kinds of reports based on status of work by tracking completion/status of rolled up parent child linked issues
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thing is, it does let you set up those hierarchies Justin described a year ago. And it provides everything you need to do the reporting you suggest, as long as you understand how Scrum/Kanban/etc work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.