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?
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.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events