A Guide to Jira Issue Types [2022]
You may use the Jira tool to divide the work into separate issues such as tasks, subtasks, bugs, epic, feature requests, and other types of issues. Each Jira software package includes a few standard issue types that are appropriate for your team’s projects.
Jira issue types are tabs that you add to issues in Jira software. Each issue type has a name that represents its function, and each named issue type also has a template, which is a particular way to organize the data for that issue type.
Jira Issue types are associated with specific Jira software packages for your company, and you must create your own templates within each package. You create a template to give a standard way to organize data for an issue type, and you associate that template with an issue type in Jira.
Must Read:
- Introduction to Jira Boards [2022]
- Jira Ticket – How to Create, View and Delete [2022]
- How to Delete Boards in JIRA? A Simple & Effective Step in 2022
Three standard Jira issue types are included with the JIRA software:
- Issue types for Jira Core (Business Projects)
- Issue types for Jira Software (Software Projects)
- Issue types for Jira Service Desk (Service Desk Projects)
The Jira issue types differ depending on the project type.
Following are the sections we are going to cover in this article:
What are the Issues in Jira?
Jira issues allow you to track a project. Not only will it help you keep track of the project, problems, and features, but you will also monitor the project through its life cycles. Here are some of the more popular Jira issue types.
People Also Watch:
List of Jira Issue Types:
Jira Issue types are listed as follows: Story, Task, Bug, Epic, Service, Incident, Problem, Change, Post-incident review, Service request with approvals, and Claim.
1. Task:
- A task is an item or work that requires completion.
- Specific activities that shouldn’t take more than one working day are planned using tasks.
- They are a component of a larger undertaking or independently designed.
- Subtasks can be created from a task.
- A capable employee can receive tasks (assignee).
- A sprint or scrum includes tasks.
- They can be actively worked on, sent to another person for input, and marked as complete when finished.
- Cross-linked tasks have the potential to obstruct one another.
2. Sub-task:
- A sub-task is the separation of a parent issue (task) into work units that one may assign and monitor separately.
- To break up larger pieces of work into tasks that are assigned and tracked individually by your teams, you may create sub-task issue types.
- If your teams just need regular issue tasks, you may opt to disable sub-tasks, which are on by default.
- All sub-tasks must be completed for a parent problem to be resolved, which is achieved by establishing workflow criteria.
- A distinct individual can work on each subtask, allowing for better tracking of the development of the primary problem.
- Sub-tasks cannot be further broken down into multiple sub-tasks and if there is any requirement to do so, then it must first convert into a standard issue before the issue can have sub-tasks.
3. Story:
- A story, or user story, is a small piece of work that requires completion.
- The most vital project information is in stories, including the project team, vision, purpose, and benefits.
- The project manager may be assigned to a story.
- The story can connect to any associated tasks. The story may be accessed via a user’s ticket to read basic information, and project leads can examine a list of all open tickets and their statuses.
- Teams promise to complete stories in the majority throughout the upcoming sprints.
4. Bug:
- A bug is an issue that restricts or hinders the product’s ability to perform its tasks.
- A bug is also referred to as “a product issue or quality issue.”
- Frequently used to keep track of issues, errors, omissions, problems, or “things to fix.”
- The bug issue type can explicitly identify a distinct problem type with a purpose.
- Some bugs may be caused by changes or implementation errors.
5. Epic:
- An epic is a big user story that requires breaking down. Bugs, stories, and tasks are in groups in epics to demonstrate the development of a bigger project.
- The software your team builds may have a new feature or experience that epics in agile development often stand in for.
- An epic is a potential parent issue and includes stories, tasks, and bugs as child issues.
- Epic problems in Jira stand for major projects or high-level efforts.
- A new feature in development by a software team can see represented in an epic.
- Epics may signify a significant service change or upgrade for IT service teams.
- Epics may stand in for significant project deliverables or phases for business teams.
6. Service request:
- A service request is a help from an internal customer service team or member.
- A formal user request provides something new.
- To enable IT teams to concentrate on producing more useful work and better enabling the rest of the company, service requests should be handled as a separate workstream.
- The majority of service requests are low risk and are automated or expedited. For instance, a request for access to a software program made by a new employee may be pre-approved and immediately granted.
- Start tracking with metrics like CSAT (customer satisfaction), time to respond, time to resolution, and time to close.
7. Incident:
- An incident is a sudden suspension of a service or a decline in the level of service.
- An incident that has a serious impact on the company and needs a quick and strategic resolution.
- It is a circumstance that impairs or lowers the standard of service and necessitates an immediate reaction.
- Teams that adhere to ITIL or ITSM best practices may refer to this as a big incident instead.
- When the impacted service begins operating in the way it was meant to, the incident reaches resolution. This just covers the activities necessary to reduce the impact and restore functioning.
- The intensity of these incidents can vary greatly, from a single worldwide online service going down to a handful of customers experiencing sporadic difficulties.
8. Problem:
- To investigate a problem that has occurred, information about it is recorded in a problem issue.
- To lessen the frequency and severity of future occurrences, problem management involves locating and addressing the causes of current incidents.
- Using the problem issue type, your service project agents may generate a problem. As a result, the recommended problem process applies to the problem record.
- Repeated incidents may be avoided and major events can be avoided entirely with a consistent problem management methodology.
- Find issues early so they may be fixed, or find solutions to problems to prevent future incidents.
- To keep teams organized and focusing on the most pertinent and valuable challenges, track and evaluate known issues.
9. Change:
- Change management, often known as change enablement, is a service management technique that reduces risks and interruptions to IT services while implementing changes to crucial systems and services.
- Any addition, alteration, or removal that could have an immediate or long-term impact on services is also a change.
- With a user-friendly service desk and automation for risk assessment and approval routing, Jira Service Management makes it easier to accept changes.
- Standard modifications are pre-approved, routine, low-risk adjustments that adhere to a defined protocol. Adding more storage or memory, for instance.
- Normal changes, such as upgrading to a new content management system, are non-emergency changes that call for additional assessment and approval by the Change Advisory Board (CAB).
- Emergency changes must happen right away due to an unanticipated error or threat. Consider fixing a big event or applying a security patch.
10. Post-incident review:
- PIRs or post-incident reviews, bring teams and individuals together to talk about the specifics of an incident, including what caused it, how it affected people, how it was handled, and how the team may avoid it in the future.
- PIRs are a crucial stage in the lifecycle of an always-on service because they allow you the opportunity to identify vulnerabilities in your system, prevent repeat incidents, and shorten the time it takes to resolve issues in the future.
- The method you choose to conduct a post-incident review is just as crucial as the duties that require completion because tensions can increase following an incident.
- A post-incident review should be reviewed after it has been written in order to close any open concerns, collect suggestions for future consideration, and complete the report, this is because an unreviewed post-incident review serves no purpose.
- If you want post-incident evaluations to be effective and help you create a culture of continuous improvement, you must put in place a straightforward, repeatable procedure where everyone can voice their concerns.
11. Service request with approvals:
- Before moving to the next stage of the procedure, some service requests might require approval.
- It’s possible that an IT manager may need to authorize requests for additional system accounts.
- The immediate manager of an employee might need to authorize a request for leave.
- A group of people that may include an information security specialist, an IT specialist, and a finance manager may authorize any mobile phone purchases that are more expensive than a specific amount.
- Jira Service Desk enables you to indicate whether an approval is required for issue types (and their corresponding request types) that are mapped to the workflow by adding an approval step to the status in a workflow.
- If the process is linked to at least one Jira Service Desk project it is possible to add an approval step.
12. Claim:
- Claim issue in Jira service management that tracks, manages and resolves the master service request or claim.
- When you create a claim issue, you can create an approval request for all stakeholders by attaching it as a content item.
- The Jira custom field ‘jira_claim_resolution_approver’ allows users to add or remove an approver for claims.
- The main author of a service request (for example an external consultant, an internal server expert, or both) can approve or decline the claim.
Wrapping Up
The purpose of each Jira issue types is to provide a unique solution to the ticket raised. Each of these issues has a separate workflow and may have a different timeline and status. If you practice to keep a track of all the ticket’s statuses it will become easier for you to solve them on time. Jira issue types help organize your tickets more efficiently.
For courses on project management and tools please check our course list.
For more information on Asana and other project management software read our blogs.
Frequently Asked Questions
How do I link Jira issue types?
In Jira, you can set up two different types of issue types: User Story and Backlog. Jira users create links between these issue types in parent/child relationship to the issue type’s content. For example, you might set up a link to a Story and use the following parent/child relationship: “S2 Story” → “Story”.
Can you create custom Jira issue types?
The custom issue for Jira projects can create custom issue types, that all project users may support. The more organized your projects are, the easier they are to manage. Using the different issue types, you can make your projects more efficient and user-friendly.
How do I have different fields of different issue types in Jira?
To have different fields for different issue types, create custom issue types first by creating a new issue type workspace under the issue types section in preferences.
Simon Calder
Chris “Simon” Calder was working as a Project Manager in IT for one of Los Angeles’ most prestigious cultural institutions, LACMA. He taught himself to use Microsoft Project from a giant textbook and hated every moment of it. Online learning was in its infancy then, but he spotted an opportunity and made an online MS Project course - the rest, as they say, is history!