Jira is used for issue tracking, and is a crucial tool for keeping large software development teams organized. In this guide, we’ll break down it’s tried-and-tested schema, including the different tiers of issue types and the organization tools offered to you.
At the time of writing, Jira is currently revamping their entire user experience. Because of this, you’ll have two options when creating a new project in Jira Cloud—Jira Classic or Jira Next-Gen. The fundamental concepts remain the same, but the UIs are different, so it’s important to clarify that the screenshots in this article are from Jira Next-Gen, rather than classic Jira.
Jira Issues
Issues are the heart of Jira. They represent individual “things that need to be done,” whether that is fixing a bug, implementing a feature, making a change, or just itemizing out work for easy assignment.
There are a few types of issues in Jira. The most basic is the regular “Issue,” also called “Stories.” You can create these from your default board by clicking at the bottom of the list and giving it a name:
If you click on an issue, a dialog will pop up showing you some more info. Issues have a few distinct fields, which are customizable in your project settings. By default, issues have a title and labels which show on the main board, as well as an extended activity list on the popup dialog.
Issues can be linked to other issues in a few different ways. It’s common for software problems to be very interconnected, so this feature is very useful. An issue can be designated as blocking another issue from being fixed, or vice versa. The vague “relates to” option can also be used for a more general link. Under the hood, Jira also uses this system to link issues that have been cloned or duplicated from existing issues.
You can also create “Child Issues” known as subtasks. These issues don’t show up on your primary board, but are linked directly to the parent issue and show up. In a way, they allow you to break down larger issues into individual pieces of work.
While they’re not on the board, they act as full issues, complete with their own identifier and all the assorted fields that come standard issues. They can be assigned to individual people regardless of the parent issue’s assignment.
On the parent issue, all child issues will be displayed in a list alongside their current state. This gives you a quick overview of how much still needs to be done, similarly to a checklist.
The final and most important type of issue are “Epics.” Epics don’t track individual bugs or features, but act as a large scale collection of issues that are all related to a particular area of work.
For example, “User Authentication” may be an Epic. Within that Epic, you may create individual Story issues to handle the login flow, create the login and sign-up pages, and possibly add OAuth 2.0 support. You may break these problem down further by creating subtasks detailing what needs to be done for each Story to be completed.
You can create Epics from the “Roadmap” tab. Because Epics usually track large deliveries of user requirements, they come with a start and due date, and can be organized on a timeline.
Otherwise, Epics work entirely like standard Jira issues. Story issues can be assigned to an Epic, which will display the Epic name alongside the issue on your boards, making them a great organizational tool. Issues linked to an Epic will display as child issues in the Epic’s info panel.
On top of this, if you don’t like the default issue types, you can customize them from Jira’s settings, and even create new ones to your liking.
Using Kanban Boards
Simply scrolling through a list of issues isn’t super intuitive, and can get clunky quickly if you have a lot of issues. One of Jira’s primary organizational tools is a Kanban board. Originating from Japanese car manufacturing, Kanban is a way of organizing items into distinct stages, also called lists. As an item, or “Card,” progresses in development, it moves from left to right along the list.
Kanban is not exclusive to or invented by Jira, as services like Trello, Gitlab, and many others have implemented boards that you may find extremely similar to Jira’s implementation. However, it’s still an awesome feature and a great addition to Jira’s toolkit.
In practice, you may create lists for issues that are backlogged, currently being prioritized, actively being worked on, pending code review, pending release, and shipped to prod. As you and your employees work on your project, issues will move from the backlog across the list.
Issues can be moved between lists by dragging them from one to another. If you’ve set up Jira integrations with your source control, you can easily move Jira issues to code review by mentioning in a commit message that it closes a particular issue ID.
While Jira focuses on using Lists to represent the chronological phases of software development, there’s no limits to how many Lists you can have, so you’re free to use them as an organization tool as well. You can also create multiple Kanban boards, allowing you to have a standard board and a custom board, using the same issues (although this feature isn’t currently available in Jira Next-Gen).
Using Sprints
While Kanban boards are a great catchall for most projects, for teams looking to implement an agile development workflow like Scrum, it can be more beneficial to organize issues using “Sprints.” Sprints are a fixed block of time, usually one month or less, during which specific issues or features are worked on by your team.
You can turn on Sprints from your project settings, which also requires that you turn on the backlog feature.
You’ll now see a “Backlog” tab that contains a list of all of your issues. This backlog allows you to plan out your Sprint. You can drag individual issues into the sprint, or order items in the backlog in order of importance and then drag the divider into the backlog. Once you’ve got something acceptable planned out, you can click “Start Sprint.”
Now, if you go back to your Kanban board, you’ll see that it is limited to the items in the sprint that you have chosen to focus on, which can clear up the clutter. In a sense, a Sprint is essentially a filter for your Kanban board.
Otherwise, it’s an entirely normal Kanban board. You can switch between the two features at will, and issues will remember their place in Kanban, regardless of whether or not you have Sprints active or not.
