Working with Issues
- Karen Jennings
- Tim C
Jira Issues Tutorial
In this tutorial, we'll explain how to work with issues in Jira software. Note that the team rituals you do outside Jira Software - like sprint planning meetings, retros, and daily standups - won't be covered here. You can read up on those in How to do scrum with Jira Software.
Time:
10 minute read.
Audience:
You're new to Jira Software, but don't really know what to do with it
Prerequisite:
- You've created a Jira Software account
You've created a Jira Software project
In Jira, teams use issues to track individual pieces of work that must be completed. Depending on how your team uses Jira, an issue could represent a project task, a helpdesk ticket, a leave request form, etc. In Jira Software, issues typically represent things like big features, user requirements, and software bugs.
Create an issue
There are a few different ways to create issues:
From the top navigation bar, anywhere in Jira
On the backlog
On your board (team-managed projects only)
Optional: Create sub-tasks
Issues can also have sub-tasks that are assigned and tracked individually. You might create sub-tasks for any of the following reasons:
- To split an issue into even smaller chunks
- To allow various aspects of an issue to be assigned to different people
- To create a to-do list for an issue
To create a sub-task:
- Navigate to an issue, and select more ( ••• ) > Create Sub-Task.
- Fill in the details as needed, and then click Create.
Estimating issues in your backlog helps you to predict how long portions of the backlog might take to be delivered.
Why estimate issues? Estimation is all about velocity.The primary purpose of applying estimates backlog items is to use that information to work out how long it will take to deliver portions of the backlog.
In traditional development teams, managers would estimate items in 'man hours'. They could then count up the hours in the backlog, divide by the number of people on the team and hours in the week to reach a forecast date. Of course, these estimates often proved to be wildly inaccurate because they didn't take into account the natural estimation characteristics of the team (for over/under estimation), unexpected interruptions or the development of team performance over time.
So in the Scrum world, most teams don't try to achieve estimation accuracy; instead they aim to achieve a reliable velocity. Velocity is a measure of the number of estimation units that a team tends to complete from sprint to sprint. After their first few sprints, most teams will achieve a reasonably consistent velocity. Armed with velocity and estimates on backlog issues, teams can predict how long portions of the backlog will take to complete.
For example, if a team has a 'man hour' capacity of 120 hours in each sprint but a velocity of 60 hours, the 60 hour velocity can still be used to estimate the number of sprints that portions of the backlog will take to complete. It may be tempting to start wondering where 'the other 60 hours' went and implying that there's something wrong with team productivity. But that's usually got nothing to do with it: a team's estimates merely represent their view of how hard items will be, and estimates will always be affected by the team's natural behaviour (for example over/under estimation) as well as organisational overhead. The velocity is all that matters from a planning perspective.
Most teams estimate using story points. Story points measure the complexity of one issue relative to others. This makes sense because the main questions to be answered are 'How much work can we realistically commit to completing this sprint?' and 'How long will this part of the backlog take to deliver?'. A story point approach can deliver the answers to these questions without the anxiety around 'accuracy' that teams feel when asked to estimate in hours.
For more information on how estimation and velocity can be tracked, check out our burndown tutorial.
To set an estimate for an issue:
- Enter an estimation.
Can I change an estimate after it has been entered? In short, yes you can. But if you changine the Estimate value after a sprint has started, it'll show up as a scope change in the burndown chart.
If you're finding it hard to estimate issues, that's totally normal! Check out our estimation guide for tips and tricks on finding the right estimates for your issues.
Rank your issues in order of priority
Ranking your issues in order of priority allows the team to see which issues they'll be working on next. To rank your issues, navigate to your backlog or board and click-and-drag your issues to order than based on priority. Here are some examples of where you might do this:
In a Scrum project, when planning your next sprint you might rank the issues in your backlog, and then decide to put the first 10 (or however many issues the team is capable of completing) into the sprint.
In a Kanban template, you might rank the issues in the To do column, and have team members take an issue off the top of the list when they need more work to do. With this approach, the column with all To do issues will need constant attention as priorities shift.
Note: You must have the Schedule Issue and Edit Issue permissions for the issue you want to move higher or lower on your board.
Flag an issue
You have the option to flag an issue, which look like this:
Flagging an issue is useful because it encourages collaboration and communication throughout the team. Here are some examples:
You're working on a task, but realize you don't have capacity to finish it off. You can flag the issue, and a team member with spare capacity who looks at the board can jump on and help.
An issue you're working on becomes blocked. You can flag the issue, add a comment explaining the blocker, and move on to the next task. Anyone who looks at the board will see that it has been flagged, and understand what's going on when they open it.
To flag an issue:
Navigate to your board.
Right click an issue.
Hit Add flag.
Transition issues
Transitioning issues shows progress across your workflow. To transition an issue from one column to another, drag an issue and place it in its new column.
Note that if you find that you're not able to transition an issue into another column, it may be because the workflow for your project is restricting you from doing so. What makes Jira so powerful is that administrators can enforce certain rules on the project's workflow, like forcing bugs to go through a QA column, or not allowing Stories to go straight from To do to Done. For more information, check out our workflow documentation.
Filter issues
An issue filter allows you to hide the issues you don't want to see, and zone in on the ones you want to focus on. Jira Software has Quick filters, which allow you to filter the issues on your board. Here's what they look like on Scrum/Kanban boards:
Search bar: Display issues that contain a search term, and hide the rest.
Quick filters menu: By default, you can filter by issues assigned to you, and issues recently updated. Any Quick filters you create will also display here.
Assignee menu: Only display issues assigned to people you select.
To create your own Quick filters (Scrum and Kanban boards):
- Go to your board, then select more (
) > Board settings. - Click the Quick Filters tab.
Enter a name, JQL query, and description for the filter. For more information on JQL, check out our advanced searching documentation.
Click Add.
Using automation as your secret weapon
Jira is the place where work lives. Sometimes a lot of work can live there! Automation is the key to keeping all issues up to date and in order. See the most commonly used automations in the Jira automation template library.