It really is a company decision on how you want to both view items in flight as well as report on them after the fact. Another thing to think about is what are your organization's definitions for sub-tasks and whether these meet the criteria.
At my company, we consider sub-tasks to be defined pieces of work that need to be accomplished in order for the story to be completed (e.g. PO Approval, Stage Testing, etc.). They don't make any sense on their own, only if they're part of a larger effort, like a story. And, if the tasks aren't completed, the story really can't be considered to be completed either.
So it really depends on what kind of relationship exists between the work items. Sometimes the relation could be that they're all part of a larger effort, so they are separate issues under the same epic. Sometimes, you can't move forward with issue A until issue B is done, so it makes more sense to use the 'blocks/is blocked by' link.
I think the most important thing you do before building anything out in Jira is to define your processes outside the scope of a tool. Just figure out how your work gets done. Then configure Jira to meet that process. I would also recommend that you keep the creation of new statuses and custom fields to a minimum, only creating them when they will help you follow your existing process.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.