You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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?
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.