What is the benefit of distinguishing issues by type?

[Scott Mains]

In my team team there is a great argument that is never to be resolved, as to whether an issue should be typed as a Story, or a Task, etc.

From the theoretical perspective, you can tell that one is a story, because it is written in story form - As a blank, I want/need blank so that blank. Another may be a task because it is written imperatively - Do x.  But this distinction is inherent in the content of the issue description.  So why is it necessary, or advantageous to distinguish these in the tool one as a story the other as a task, or subtask for that matter?

One difference in the tool between a Story or task and a subtask, is that you cannot add subtasks to a subtask, and that you cannot convert a subtask to a task or story, though you can change a task to a story or an epic even.  Why?

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

It's because you might want certain things to behave differently.  The issue type tells Jira how you want to handle issues of that type.  It's not uncommon to handle stories, tasks, bugs, defects and sub-tasks differently, no matter what level (issue or sub-task) they are at.  You can't assume that a computer will know that you want to do something differently based on a guess after reading what a user has entered.

No, you can't add sub-tasks to sub-tasks, this is deliberate - when Jira was written, the industry was snarled up with issue trackers that did let you do that and they were letting people get into a total mess, whether utterly unable to find anything or subjecting people to counter-productive micro-management.  As a general rule, they're a terrible idea.

You can convert sub-task types upward into issue-level types - there's a "convert to" option in the tools menu (in the same place that issue-level types have a "convert to sub-task")

[Scott Mains]

Thank you for pointing me to the "convert to" option.  I was attempting to do this through another mechanism,  clicking the issue type icon, which works for some reason when converting a story to a task or other type, but not for elevating a subtask to a task or story.  In my case I had converted a story with subtasks into an epic, and wanted to convert the subtasks to stories in the newly converted epic.  They were staying as subtasks in the epic and I couldn't figure out how to elevate them.

So I think one reason my team is struggling with this debate, is that we are not aware of much less making use of the tool automations, workflows and other concepts inherent in these types, such as the reporting.  I think at most the debate has centered on enforcing a structure, e.g. epics only have stories, stories only have subtask, and don't use tasks, exceptions being occasion we will use mark an issue as a bug or a spike.

Does anyone have thoughts on why or why not enforcing such conventions would be beneficial or not?

[Nic Brough -Adaptavist-]

Ah, yes, that makes sense.  It's not something that obvious in Jira until you get used to it, but the issue type is a very important structural item, and all the config for issues hangs off it.

You can only use a simple "edit" to change the issue type when the source and target issue types have similar configurations - specifically, they have to be set up to be using the same fields and workflows, and they have to be types at the same level in the hierarchy (Issue or sub-task).

Enforcing a convention is beneficial, because it enables everyone to work together, using a common language and understanding.  But I wouldn't limit yourself to a convention that your people don't agree on.  Get your people together and hammer out a convention that works best for all of you! 

You've said "only have stories, stories only have subtask, and don't use tasks, exceptions being occasion we will use mark an issue as a bug or a spike", which is perfectly fine, but I personally wouldn't stop people using tasks at an issue level (same as stories are), with the understanding that while they're not stories, they're things that need doing, so they get estimated and make their way to "done" as though they were stories.  Similarly, I'd be tempted to let people have more than one type of sub-task (technical task, defect, even things like "fragment", which developers have found useful because they can assign different sub-tasks to different people)

[Trudy Claspill · Accepted solution]

Two potential advantages for having different types of issues at the Story/Task/Bug level:

- Being able to have different workflows based on issue type (in Company Managed projects only at this time, not available in Team Managed projects)

- Easier to generate reports for different types of work based on issue type

Having different types of issues may depend on what type of work you want to track. For instance:

Are you only tracking work that is directly related to the product, or do you track non-product work like training activities?

Do you want to be able to distinguish work that correlates to code change from work that might be only research with no code change?

Do you have documentation work to do that would not be included within the scope of another work item?

[Sachin Dhamale · Accepted solution]

@Scott Mains 

Welcome to the Community

Issue types distinguish different types of work in unique ways, and help you identify, categorize, and report on your team’s work across your Jira site. 

Multiple issue types help you search and sort the work your team takes on, track the progress of specific types of work.

+ 

You can distinguish parent and child issue 

+ 

You can have unique workflow, field, screens per issue type.