Should you create a sub-task issue if there are standard issues that cover the same work

[Kimi Nakashima]

Here's the situation. We have several requests available for our customers in the portal; they can request everything or they can request the pieces. These requests are linked to issues Foobar, which is everything or Foo and Bar, which are the pieces.

We'd like to break down issue Foobar into smaller pieces since typically more than one person would be working on it. It's my understanding that you would use sub-tasks to do that. But we have existing standard type issues, Foo and Bar, that essentially cover the same work that the sub-tasks would.

So is it better practice to create the sub-tasks so that we can utilize the parent-child relationship, even though it'll create what is essentially a duplicate issue type? Or should we just split the big issue into the 2 smaller issues and use a relates to link? 

[Petter Gonçalves]

Hello Kimi,

Thank you for reaching out.

I believe there is not a right/wrong way to configure your issue types hierarchy in the current scenario you have. You could use the parent-child issue link or the conventional link between the standard-issue type.

Also, there's the possibility to use Epic issues as the top parent, instead of Standard issue type.

Personally, I would use a standard-issue type (Foobar) and two sub-tasks (Foo and Bar), because this way you can have the sum of both issues estimation/time spent together or separated, also allowing you to group the final considerations in a single view (The parent issue).

If you still have questions about what would be the better option, please feel free to provide us more details (Estimation, management, reports) you want to implement so we can better visualize your scenario.