In the previous chapter, you saw that JIRA is a very flexible and versatile tool that can be used in different organizations for different purposes. A software development organization will use JIRA to manage its software development lifecycle and for bug tracking, while a customer services organization may choose to use JIRA to track and log customer complaints and suggestions. For these reasons, issues in JIRA can represent anything that is applicable to real-world scenarios. Generally speaking, an issue in JIRA often represents a unit of work that can be acted upon by one or more people.

In this chapter, we will explore the basic and advanced features offered by JIRA for you to manage issues. By the end of this chapter, you will have learned the following:

Understanding issues

Depending on how you are using JIRA, an issue can represent different things and can even look very different in the user interface. For example, in JIRA Core, an issue will represent a task and will look like this:

While in JIRA Software, if you are using the agile board, an issue can represent a story, or epic, and will resemble a card:

Despite all the differences in what an issue can represent and how it might look, there are a number of key aspects that are common for all issues in JIRA, as follows:

• An issue must belong to a project.
• It must have a type, otherwise known as an issue type, which indicates what the issue is representing.
• It must have a summary. The summary acts like a one-line description of what the issue is about.
• It must have a status. A status indicates where along the workflow the issue is at a given time. We will discuss workflows in Chapter 7, Workflows and Business Processes.

So in summary, an issue in JIRA represents a unit of work that can be completed by a user, such as a task in JIRA Core, a story in JIRA Software, or a request in JIRA Service Desk, are all different forms of an issue.