Jira Concepts - Issues
Jira tracks issues, which can be bugs, feature requests, or any other tasks you want to track.
Each issue has a variety of associated information including:
- the issue type
- a summary
- a description of the issue
- the project which the issue belongs to
- components within a project which are associated with this issue
- versions of the project which are affected by this issue
- versions of the project which will resolve the issue
- the environment in which it occurs
- a priority for being fixed
- an assigned developer to work on the task
- a reporter - the user who entered the issue into the system
- the current status of the issue
- a full history log of all field changes that have occurred
- a comment trail added by users
- if the issue is resolved - the resolution
Issue Types
Jira can be used to track many different types of issues. The currently defined issue types are listed below. In addition, you can add more in the administration section.
For Regular Issues
-
Initiative
-
Epic Story
- Created by Jira Software - do not edit or delete. Issue type for a user story.
-
Feature
- The most common type of PBI is something that is of value to a user or customer. PBI that represents items of functionality that have tangible value to a user or customer. These can be brand-new functionality or changes to existing functionality. Features, for most teams, should represent the overwhelming majority of items in their backlog! The litmus test for these types of items is simple. Hand the item to one of your users or customers and ask her what she thinks. If she says, “I love it, when do I get it?” you have a feature. If she has no clue what you are showing her, then you don’t have a feature; instead you have something else that might still be considered a PBI, but a different type of PBI.
-
Technical Work
- Things the team needs to do to work more efficiently or to allow the product to function better as a whole. Examples might include upgrading to the latest version of the Oracle DBMS or refactoring a section of previously completed code.
-
Defect
- High-performance agile teams never let defects live long so they are unlikely to ever have many defects in their product backlogs. But what if your team is working to become high performing or you are working on a defect-ridden legacy product that you inherited? In these cases you will have defects and many teams include at least the high-priority ones in their product backlogs.
-
Support Request
- Generally speaking unplanned work, such as production problems or user help requests
-
Knowledge Acquisition
- During agile development, when we are presented with a high degree of uncertainty, a common and effective solution is to buy information. Buying information has a number of more common names: prototype, proof-of-concept, research, experiment, spike, etc.
-
Work Task
- The technical work that a team performs in order to complete a product backlog item. Most tasks are defined to be small, representing no more than a few hours to a day or so of work
-
QC Issue
- QC Issue
For Sub-Task Issues
-
Sub-task
- The sub-task of the issue
-
QC Issue
- QC Issue
-
Work Task
- The technical work that a team performs in order to complete a product backlog item. Most tasks are defined to be small, representing no more than a few hours to a day or so of work
Priority Levels
An issue has a priority level which indicates its importance. The currently defined priorities are listed below. In addition, you can add more priority levels in the administration section.
-
Critical
- Crashes, loss of data, severe memory leak.
-
Standard
- Standard helpdesk request
-
None
-
Blocker
- Blocks development and/or testing work, production could not run.
-
Minor
- Minor loss of function, or other problem where easy workaround is present.
-
Major
- Major loss of function.
-
Trivial
- Cosmetic problem like misspelt words or misaligned text.
Statuses
Status Categories
Helps identify where an issue is in its lifecycle.
Issues move from To Do to In Progress when work starts on them, and later move to Done when all work is complete.
- Done
-
Represents anything for which work has been completed
- In Progress
-
Represents anything in the process of being worked on
- No Category
-
A category is yet to be set for this status
- To Do
-
Represents anything new
Issue Statuses
Each issue has a status, which indicates the stage of the issue. In the default workflow, issues start as being Open, progressing to In Progress, Resolved and then Closed. Other workflows may have other status transitions.
- To Do
- Stalled
- Issue cannot progress further until some external condition changes
- In Progress
- This issue is being actively worked on at the moment by the assignee.
- In Review
- Done
- Ready For Development
Resolutions
An issue can be resolved in many ways, only one of them being "Fixed". The defined resolutions are listed below. You can add more in the administration section.
- Done
- Won't Do
- This issue won't be actioned.
- Duplicate
- The problem is a duplicate of an existing issue.
- Cannot Reproduce
- All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the issue.
- Rejected
- This issue was not approved.
- Declined
- This issue was not approved.
- Resolved
- Remove Me
- Fixed
- Remove Me
- Task Completed
- Remove Me
- Won't/Can't Fix
- Remove Me
- Incomplete
- Remove Me
- Information
- Remove Me
- Spam
- Remove Me