What is the benefit of distinguishing issues by type?

Question

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 Answer

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")

Trudy P Claspill · Accepted Answer

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_o1c5zi · Accepted Answer

@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.