Use and create custom issue types - Jira Tutorial

- Let's take a deeper look at the common areas to customize, which are issue types, workflows, screens, and fields. At the end of the section, we'll use what we've learned to create templates, to use as a standard configuration. In this section, we'll define Issue Types, Issue Type Schemes, and discuss best practices for creating custom types. issue types provide structure in Jira projects. They help distinguish between requests like stories and tasks or incident and change requests. The issue types admin page shows all the issue types in the application. Whether they are standard or custom, and which schemes use them. In this screenshot, the first issue type is used to collect user questions. The Ask a question issue types is standard in Jira service management. The second is used to report a defect to fix. The bug issue type is standard in Jira software. Ideally you want the fewest amount of issue types in your Jira project. So I like to start people out with epic, task, and sub-task. And then when there's a business need for more, that's when you want to add more. And you also don't want to add issue types until there's a need for different workflows, different screens, or both within the same project. To create a custom issue types, click the button on the top right. All issue types contain the following attributes, a unique name to identify it, an optional description, a type which is either standard or sub-task, and an icon to help visually identify it. Users see the icon when they create issues, in user objects like filters, boards and dashboards, and an email notifications. Users see the description when they hover over the icon. You can also translate the name and description into a different language if needed. Finally, an issue type may be part of an issue types scheme, which is used by one or more projects. Different issue types can have different behaviors. For example, a bug can have a different workflow and different screens than the story. Also in the issue types admin area are sub-tasks. I find the naming of standard issue type and sub-task issue types, a little confusing. I like to think of standard issue types as parents and sub-task issue types as children. For example, if the parent type is task, the child type is sub-task. But sub-tasks aren't limited to only being children of tasks. A sub-task can be a child of any other issue type. For example, it's common for development teams to break up the work required to complete a story into multiple sub-tasks. Additionally, just like you can create custom parent issue types, you can also create custom child issue types. One company I worked with created a child type called sub-bug and used it to distinguish those child issues from other child issues. What do you think? Is this a good use of a custom sub-task or is this overkill? I'll let you be the judge. To create a custom child issue type, click the button on the top right. All sub-task contain the same attributes and benefits as issue types. It's also possible to disable sub-tasks application-wide. I don't recommend it though. Sub-tasks provide an inherent parent child relationship that helps organize information. The relationship is also queryable. In my experience, organizations always want to add more levels of hierarchy, not remove them. When you create a new parent or child issue type, it is automatically added to the default issue type scheme. If you want the issue type available in other issue type schemes, you'll need to add it manually, by clicking the Edit button. Here's the tip. You can't remove issues from the default issue type scheme, and you can't delete the default scheme either. It serves us fallback for any projects without a custom scheme. Since the default scheme contains all possible issue types, that list can be quite long. Also it might contain types that simply don't apply to a certain Jira project. Rather than assigning the default issue type scheme to a project, I'd like to create a custom scheme for the main use cases. For example, one scheme that contains all the issue types for Dev projects. A second scheme that contains only epic, task, and sub-task, for all the task type and business projects. And a third scheme that contains all the support issue types. Here are some best practices. Use the default issue types until there's a business need to create custom ones. If you create custom types, choose generic names so they can be used by multiple projects and schemes. Use sub-tasks which help users break up large issues into manageable pieces. Order the issue types in the issue type scheme, alphabetically, or by frequency of use so users can find the right one quickly. Here's the tip. Each issue type scheme could have one issue type that shown first. For each scheme, ask yourself which issue type will be used most often. If you're not sure, leave this blank and set it later. For this example, I've assumed there will be a lot of bugs and I have made that the default. Here are some things to avoid. Don't create unneeded issue types. Issue types exist to allow different workflows and screens. If all issue types use the same settings, you might have more than you really need. Next don't create new types for each new project. I made the mistake in the beginning because I followed the mistakes of previous admins. Just like schemes, issue types are meant to be shared. Finally, don't create super specific or duplicate issue types. For example, for any type of development problem, use the standard bug issue type. Don't also create defect. Try to get teams to use the same terminology whenever possible. Further, don't create custom types like production bug and staging bug. Instead, create a custom field called environment to capture the location of the bug. When naming, try to group similar activities together. In the second example, one issue type called access is better than three issue types, representing different kinds of access. Always think about how you want to report on the data. You can leverage custom fields, labels, and components to help differentiate between requests. Reporting needs should dictate the Jira implementation method not the other way around. Here's a mistake to avoid. How many different combinations of issue types could a company possibly need? One company had 134. Now this was not because they were actually needed, but because new types and schemes were created for every new project. At the same company, there were a few projects that use the default issue type scheme, which contains every available issue type. Reporters in that project were overwhelmed when creating a new issue. They had to wade through 134 available selections. The choices weren't even listed alphabetically. The project leads couldn't easily report on or segment the issue the teams were addressing. Instead, don't create too many issue types and don't assign the default scheme. The legal team wants to track their contracts and agreements in Jira. Because the contract process has a different workflow than their other work, and there are contracts specific custom fields, a new issue type is warranted. Let's create one for them. First, I'll go to the issue types admin page and click the button at the top right. Next, enter a name and a description and click the Form Submission button. Next, let's give the new issue type an icon so it's easy to visually identify. Then click the Form Submission button. Now we can add the issue type to the legal projects, issue type scheme.