What happened to the parent-child issue link type in JIRA?

[Anthony Pelosi]

What happened to the parent-child issue link type in JIRA?

Is there a better way to establish parent-child relationships than adding back in a custom issue type for parent-child? I haven't used JIRA since before Scrum and Kanban boards were introduced, so guessing this functionality has been swallowed up by Epics or some other functionality.

Example: I create an issue for a feature called "Ability to Attach a Photo". Then a create issues for "Ability to Attach a Photo using Camera Roll", "Ability to Attach Photo using Camera", "Ability to Attach a Photo using...". I don't want to create them as sub-tasks because they are independent features on their own and we don't have to complete every single one in the same sprint. In the end, "Ability to Attach a Photo" will not have any work logged against it directly, the work logged will be the sum of the child issues.

Options:

1. I could make "Ability to Attach a Photo" an Epic, but then I'd have tons of Epics, and "Ability to Attach a Photo" is already part of an Epic to begin with. So I don't want to do that.
2. I've thought about creating a custom issue link for parent-child but I'm guessing there is a good reason it was removed by default - just not sure why yet!
3. I don't create the issue "Ability to Attach a Photo" to begin with because it's just for helping out the product/project manager and doesn't translate into any work for the developer. I don't like this either because I often create issues without knowing how it will be implemented (I know that I want the ability to attach a photo without knowing how many different options to support) and I don't want to be discouraged from creating the issue into the implementation has been flushed out.
4. I could make each of the child issues sub-tasks, but then they are directly tied to the parent, and I can't assign them to separate sprints. I'd like to implement "Ability to Attach a Photo using Camera Roll" and "Ability to Attach a Photo using Camera" first, and then additional options in a later sprint. 

So none of these solutions are really good. Any suggestions would be extremely appreciated!

[MattS · Accepted solution]

Old school, dude! I'd use JIRA Agile and Epics. The Epic Link field shows the related issues which can be from any project. Or just use an existing link type such as Relates. The parent child issue link may well have been a custom one someone created locally, I don't recall it being a standard one. Keep tweeting those runs!

[Anthony Pelosi]

Hi Matt, Yes, old school! Been forced to use Pivotal Tracker recently and helping someone get started with JIRA. Your answer is what I was afraid. I can feel the Epics going from a few dozen to a few hundred. From Atlassian's documentation at https://confluence.atlassian.com/display/AGILE/Working+with+Epics, "An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories." In the scenario above (which is just one of many), we essentially have a small user story, not a large one. I'm worried that Epics will lost their effectiveness once there are that many of them and they become less distinguishable from stories. So for small user stories such as attaching a photo to a post, we'll see how Epics work, and if that doesn't work out then we'll add in a parent-child issue link. Thanks for answering and hope all is well at ServiceRocket!

[Timothy]

I think you will just need to recreated the Issue Link (https://confluence.atlassian.com/display/JIRA/Linking+Issues). Sub-task should work also but they are of course considered "sub-task" type and not the same level as a "parent".

[Anthony Pelosi]

Hi Timothy, I responded about sub-tasks above, not gonna work because I want to assign to different sprints. As far as re-creating the parent-child issue link I had listed that as Option 2 above. If that's the best way, and I'm guessing I'm not the only one in this predicament, then why would Atlassian have removed this issue link in the first place?

[Timothy]

It's just a type that you can recreate :)

[Anthony Pelosi]

Since it used to be there by default and it is no longer there, I am guessing it was removed - not because it was not utilized by users - but because a better way to establish parent-child relationships was implemented. Atlassian doesn't remove a default option like that without careful scrutiny. The only thing I can think they added to replace it would be Epics (sub-tasks have always been there and don't allow for sub-tasks of the same parent to be assigned to different sprints), but then we'd go from 2 dozen epics to hundreds.

[Jim Lynch]

There is sub-task.  It works under task, ticket, etc.  I would think it will meet your needs.

[Anthony Pelosi]

Hi Jim, I just updated my question with one more option. "I could make each of the child issues sub-tasks, but then they are directly tied to the parent, and I can't assign them to separate sprints. I'd like to implement "Ability to Attach a Photo using Camera Roll" and "Ability to Attach a Photo using Camera" first, and then additional options in a later sprint." So sub-tasks doesn't work for me in this case. Thanks for answering!

[Adela Salagean]

Anthony, browsing for answer to same problem - did you solve the child issues in separate sprints problem?

[klentabistado]

Same here. Struggling on how to overcome this scenario.
Have you found your way Adela?

[Bruce Chalupsky]

Same, the Jira Hierarchy is too limited. Stories are supposed to fit into sprints per INVEST, there needs to be a level above the Story (Azure, Rally both do this btw) to keep stories from becoming mini-epics or meta-stories that constantly WIP sprints.  Scrum teams need to swarm but also break apart items to focus on, XP devs use this process all the time.  At least allow a Task to use the Parent link to stories so subtasks can use the sprint constraints.

[MBailey]

I agree, the out of the box setup is problematic.  We are having exact same issue as was outlined above, where our Epics are used to represent larger items and we want the ability to Draft a set of top level US's which each also represent independent customer value (INVEST).  In some cases we will just task out these US's, but in other cases, we need the ability to break down the top level US into child US's so that the work can be spread across more than one sprint.  JIRA seems very limited in this way as compared with RALLY and Azure.   I am not sure how we going to get out of this predicament.