I’ve had a number of people ask me lately, “how can I use priority to better manage issues inside of JIRA?” Throughout my career in software different teams have used priority to communicate different processes inside of their issue tracking systems. Failure to be crisp about the definition of priority makes work more confusing to get done.

Allow me to set a few global definitions to frame our discussion:

  • Priority – The relative importance of an issue in relation to other issues for the team.
  • Severity  The relative impact of an issue as compared to other issues reported from test, development, or the field.
  • Frequency  How often a particular issue surfaces.
  • Blocked  A case where a member of the team is prevented from making progress.

Priority is always reflective of the order in which engineers should work on issues. Straying away from that definition makes work harder to complete, since the team won’t always know how to take the right next step.

Prioritize consistently

Effective teams prioritize issues consistently as the team’s culture matures. Chances are, you’ve heard one of these statements on your team as you’ve worked through organizing issues in your next iteration.

  • “This issue should be top priority because it’s very severe!” (high severity)
  • “A lot of people will run into this issue so we should make it high priority” (high frequency)
  • “I’m blocked from making forward progress so this issue should be high priority.” (blocked)

Let’s take a look at some follow-up questions we should ask.

  • What is the worst thing that could happen as a result of this issue?
  • Will the user lose anything of significant value?
  • How many users do we think are affected?
  • Is the issue confined to a certain area of the product, or will all users face this issue?
  • Does it prevent forward progress of an end user, or someone on the development team?

Software engineering is an economic process. If you decide to fix one issue, it means you’re delaying working on something else. Therefore it’s important to optimize the order in which you fix issues so that your team is delivering the most value. Regardless of how issues are prioritized, priority only refers to the order in which they should be fixed.

Pro tip: Prioritization is a cultural element in every team. Reviewing and prioritizing issues as a team helps build a foundational understanding of the team’s values and goals. Don’t underestimate the need for triaging issues together, especially for new projects.

Traditional teams: Use JIRA’s priority field

Traditional software development teams should use the priority field inside of JIRA. JIRA includes five default priorities (blocker, critical, major, minor, trivial). Teams can add or change priorities inside of JIRA to fit their needs.

Priorities typically exist inside of versions so that engineers fix all issues with a version first based on priority and then move on to the next version. Put explicitly, a blocker in version 2 would come after a major issue in version 1. The two dimensional filter statistics gadget summarizes priorities across concurrent versions. Project managers can get an overview of the project in one glance.  To drill down, just click any of the links.


Use the fixed version field to target which release an issue should be resolved in. The affects version field tracks what version the issue is found in.

ProTip: Some teams prefer to change the default priorities to a numeric scheme: P0, P1…P4. This removes the emotional attachment to words like “blocker, critical, and trivial”. Just be clear about what each of the numeric states mean so the team prioritizes consistently.

Agile teams: Use rank

Agile teams have a slightly different way of prioritizing issues. Agile teams deliver new work by working via a backlog which is a list of all issues on the team’s radar. The list is always in a prioritized order so that the team can simply pull work off of the top of the list.   Iteration based scrum teams work by sprints. They pull a set issues from the top of the backlog to work on during an iteration.  Flow based kanban teams continually pull the top item off of the backlog.

Agile Teams_Use Rank

Agile teams don’t need the priority field as the order of the backlog sets the priority.  As priorities change within a backlog the team remains unaffected as they are only concerned with the first few issues near the top. JIRA agile makes it easy to filter work by version so the product owners can manage priorities with an a version as well as work at large. Some teams like to use rank and the priority field as the priority field gives a bucketed grouping of relative priority.  You can then query those buckets using issue search or the various dashboard gadgets.

Leveraging flags

Sometimes when working on an issue, another issue will arise blocking progress. In this case forward progress is blocked. With JIRA Agile, team members can flag an issue noting they are blocked. It turns yellow on the agile board with a flag icon noting the impediment.

Leveraging Flags

The priority of the issue does not naturally increase due to the fact progress is blocked. The team weighs the consequences of being blocked against the current work and determines if priorities need to change.

Align through clarity

Teams aligned on the priority of the work ahead of them execute more smoothly and deliver more quickly. Always be in the practice of listening within the team to see if priorities are clear. Ask “Is it easy to determine what the team’s next priority is?” during retrospectives. If there is confusion, spend some time focusing the team’s prioritization practices and then model that practice in JIRA.

About Dan Radigan

Software has been a passion since the days of the floppy disk (you know, the actual 5.25 inch floppy ones). Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling. Find me on Twitter: @danradigan.

View all posts by Dan Radigan »