In this video, we will discuss issue types. We will start with an overview of issue types. In Jira, an issue is a generic name for a unit of work. And your projects, they're usually different types of units of work. The issue type field is used to differentiate these. When you create an issue, you can choose the issue type. You can also change the issue type after creating it. Notice that each type has an associated icon to help easily identify the issue type. A story is a requirement from the users perspective. A task is a work item that needs to be done by the team, but is not directly tied to a user requirement. An example might be upgrading the version of a product used by the team. A bug is a flaw that needs to be fixed in the product. It can be tracked with its own issue type to differentiate this work from other types of work. An epic is a big issue that can contain other issues. A subtask is a part of another issue. It is used to break an issue down into specific pieces of work. When creating an issue, subtask is not shown in the issue type dropdown because subtasks must have a parent issue. They cannot be created independently. In addition to these out of the box issue types, you can create custom issue types. This provides your team the flexibility to work the way that they want to work. How the team actually defines with each issue type means is entirely up to them. Also, a different projects can use different issue types. There are several reasons to use issue types with your projects. They support different types of work items. A team usually doesn't have only one type of work and issue types allow the team to differentiate those. Each type can have different fields, screens, and workflows. For example, you might want bugs to appear at the top of the project sport. You can also report on issue type separately. For example, because the issues of the project have been categorized by issue type, you can easily create a report with the number of bugs fixed in the previous week. We will discuss each of these more later. Next, we will discuss subtasks. Subtasks are an issue type that must have a parent type. To create a subtask, you click on the create subtask icon for the parent issue. Subtasks allow an issue to be broken down into individually manageable tasks that can be assigned to different team members. Subtask can be more technical than the parent issue. For example, if the parent issue is a story, the story will be written in nontechnical language that all team members and stakeholders understand. But the subtasks can be written for the technical person implementing the subtask. Subtasks have their own issue keys and fields. Here is the story with two subtasks. Each subtask has its own issue key and summary field value. The subtasks have independent workflow statuses and move through project boards in dependently. Since subtasks have their own issue keys and fields that can be converted to other types of issues. To convert a subtask to another type of issue, view its details, then click on the more icon and select Convert to issue. Converting a subtask to an issue involves a few steps. The first is to select the new issue type. Here we are converting a subtask to a task. You are then prompted to optionally change field values for the issue. You can also convert other issue types to subtasks. Click on the more icon for an issue, an select Convert to subtask. When converting an issue to a subtask, you must select the parent issue. You will then be prompted to update the subtasks field if desired. Next, we will discuss editing issue types. Creating and modifying issue types is done for the project by navigating to the project and then selecting project settings. This allows you to administer the project. After navigating to the settings for the project, click on issue types to view the issue types for the project. You can see that this project has five issue types. These are the default types for Kanban projects. The issue types for Project are organized into something called an Issue Type Scheme. Schemes are commonly used behind the scenes in Jira to organize a collection of related things. The Issue Type Scheme name includes the project key. You can change this issue type scheme without affecting other projects unless some other project decided to use your scheme. Notice that each issue type can have a unique workflow associated with it. All of the issue types use the same workflow, so they will all go through the same status is. Each issue type can have unique fields allowing you to customize an issue by issue type. In this case, all of the issue types use the same field configuration, so the field names are the same for all issue types. Each issue type can have unique screens. The screen is a user interface element used to show fields to users in a context appropriate way. For each issue type a screen scheme is used. Screen schemes are collections of screens. In this case, all of the issue types use the con bon default screen scheme with the exception of bugs. The screens for bugs are slightly different than other screens. To show bug related fields that would not normally apply to the other issue types. To change something related to your issue type scheme, click on actions. You can see that you have two basic options. You can edit this issue type scheme or you can reuse an existing scheme. As an example, we will click on edit issue types so that we can make a minor change to the existing issue type scheme. Before we click on this, notice that we are still in the settings for the project. Here's the modify issue type scheme screen. Notice that we have changed from the project settings context to the settings for the entire Jira application. This is because issue type schemes can be shared by more than one project. Jira has navigated you to the issue type scheme section and selected the issue type scheme for your current project. On this screen here you can modify the scheme name. Here you can add a description. Here you can change the default issue type that is selected when you create an issue. When we first created issues earlier in the course, they were stories. Because of this setting. Here's the list of issue types for the current scheme in the order that they would appear in a drop down list. You can drag and drop inside of this list to change this order if you don't want to use one of the issue types in your project, you can drag it from the list on the left to the list on the right. The list on the right contains any issue types that are defined in your Jira account that are not used by your project. For example, a custom issue types from other projects would appear here. If you want to add an issue type to your project, click the add issue type button. Here's the screen that appears when we click the add issue type button. You can create any issue type that makes sense to your team. Here we have created an issue type named Small. This might be created because the team has a policy that all work must be tracked in Jira. Even items that take a small amount of time to complete. This differentiates this type of work from bigger issues, allowing you to report on them only if necessary. For example, you can exclude these from a cumulative flow diagram. When adding an issue type, you have the option of creating it as a standalone issue type or a sub-task. If you select sub-task, this issue type must have apparent issue. You could not create them in dependently. Once we have added an issue type, it appears in the list of issue types for the project. We could change the order of appearance by dragging it to a different location in the list. When you are happy with the changes to the issue type scheme, click save. After modifying the issue type scheme to your brings us back to the settings context for our project. Our issue type scheme now shows the added issue type. Notice that our issue type has been given an icon. It also has been assigned the same workflow, field configuration and screen as most of the other issue types in the project. Any of these can be changed. To change an issue type, navigate to the Jira application settings and select issues. Then issue types. Here we can see our new issue type with options to edit, delete or translate the issue type to a different language. Now when we create a new issue in our project, we can select our new issue type. Next we will discuss using issue types in queries and swim lanes. Basics. Search has a type dropdown that contains the issue types. In your dear application. You can see that this contains the default issue types as well as any custom types. We can see our new small issue type in the drop down. Here we have searched for all issues with the small issue type. If you click on the advanced search you will see that this issue type field is searched in the query. A swimlane allows you to horizontally organized issues with certain characteristics on a board. For example, you could have a special role for expedited issues. Here we have created a swim lane for our small issue type. So that the small tasks are separated from normal issues on the board. Swim lanes are configured using the swimlanes tab under board settings. We have chosen to base our swimlane on queries and have added a swimlane named small tasks. The JQL for the swimlane can select from any subset of the boards issues, and this query selects for issues with an issue type of small. Any issues that are returned by this query are placed in a separate row on the board. Every other issue that the boards filter matches will be shown under the everything else heading. We can drag and drop the order of the Rose here if we would like to move the small tasks wrote to the bottom of the board. Here again is the board with the swim Lane. You can see that our query selected one issue for the small tasks swimlane. And the rest of the issues that match the boards filter are shown under the everything else heading. Here's a review of what we've discussed in this video. Each issue has an issue type field that identifies the type of work of the issue. Each issue type can have unique fields, screens and workflows. So tests are issue types that must have a parent issue. A collection of issue types used by projects is called an issue type scheme. Jira allows you to customize issue types for each project. Swim lanes can be configured on boards using any field including issue type. Now it's time for you to work on some of the things that we've discussed in this video. Separate hands-on instructions are provided for you.
