Task vs. Subtask - Story vs. Subtask

[Brenda Xuereb]

Hi All!

I would like to debate one aspect which I have seen in the business which is not something I had been familiar with in my previous companies when working with Jira. 

Some projects utilise Task and subtasks as parent-child relationship which that I am familiar with however I have also seen where people create story & subtasks of such stories.

I am of the understanding this is being utilised by different departments within the same project however I would like to understand whether this is the best practice of doing so? 

Thanks!

Brenda

[Rob Horan · Accepted solution]

I always loved having very distinct issue types to distinguish work (new feature vs enhancement vs cosmetic fix) but I find that not everyone likes that kind of differentiation.

[Brenda Xuereb]

HI @Rob Horan

Thanks for your insight. I cannot wrap my head around this reasoning however it might be down to the idea of notion that I have not yet understood how this is being utilised across some projects. 

As a systems admin I can only suggest ways forward however I am trying to keep an open mind and understand if this is the 'normal' ways of working in some companies so I can adapt to that train of thought.

Thanks!

[Matt Parks · Accepted solution]

It really depends on how granular you want to get with your issue types. At our company, we don't use Tasks at all, mainly because we migrated from TFS and, in that environment, a Task was typically used as a child of a Story/Bug (although it could be unparented) and we wanted to minimize confusion around an issue type called Task that couldn't be a child of a Story.

My recommendation is that, whatever issue type you use, it has a very specific use case. In our environment, anything that is a Story is something that will be deployed/implemented. We created a new issue type called General Item, which is used to track things like research or documentation, where the teams are doing work that you want to track, but it doesn't go through the standard deployment process and you don't have something that will necessarily provide value to the end user.

So I would recommend that teams know exactly why they would create a Task as opposed to a Story, but what that reasoning is will be up to your organization. This will allow for better reporting in the future, since there will be consistency in the environment.

[Rob Horan]

It's a personal thing, but it irks me to see that there is the capability EASILY to distinguish various types of work with issue type, and so many are like, Hey, look, this is a story, and that is a story and that other thing that's completely different is also a story.  I can empathize with Alison Burke in this way:

https://youtu.be/cUbIkNUFs-4?si=eEdpwmGoTV0b_qly