JQL Queries for Analyzing Team Performance in Jira

[#1]

As teams grow larger, the next questions appear: Are we moving fast enough? Who is overloaded? What are the bottlenecks?

Jira has built-in reporting features, but they do not always provide the complete picture. Here’s a short checklist of team performance metrics and how to track them with JQL queries. We will also briefly show how to address the JQL gaps using the Issue History for Jira app.

📦 Task Completion 

Measuring the team's progress in a sprint or a month is one way to understand output.

In Jira, you can use JQL queries to get the list of work items that are completed or not completed in a specific sprint. For example: 

• To get the list of completed tasks in a specific project and sprint: 

project = MARK and sprint = 34 and status = Done

• To get the list of unfinished tasks (e.g., In Progress, To Do) from a specific sprint:

project = MARK and sprint = 34 and status NOT IN (Done) 

Also, you can use such a JQL query to receive work items completed in a specific period (for example, in the last 30 days):

project = DESIGN and status = Done and resolved >= -30d

Compared to JQL, which only presents the current status of the work items and requires numerous queries, Issue History for Jira app gathers all the historical changes into a single report. 

In the app, you may select the project and date range needed or choose the specific sprint. Then, use a filter on the Status field that corresponds to your needs. This immediately displays the entire list of tasks and the person responsible for them. You can export the list to use in sprint reviews or a management report.

🔄 Reopened Work Items 

Completing a task is not necessarily the end of a task. In some cases, work items can be reopened because of the following reasons:

• acceptance criteria were not completely satisfied,
• bugs found after their closure,
• reviewer or tester had asked to make changes.

It is worth tracking reopens as they are also a quality indicator - a sign of wasteful work or a weak definition of Done.

You can use JQL to find work items currently in Reopened, for example:

project = MARK AND sprint = 34 AND status = Reopened

This shows items that are still reopened right now.

The limitation is that JQL only displays the current status. The reopened then closed work items will not be shown. This will mean you don’t get the complete picture of how many times reopens occurred in a sprint.

Unlike JQL, Issue History app keeps a record of all status transitions. Using this app, you can instantly see all the work items that were transitioned to the Reopen status during the sprint, who performed the reopen, and the exact date and time it happened.

When the same work items are reopened repeatedly, it often indicates quality or communication problems, such as bugs getting through or unclear requirements.

🚧 Bottlenecks (Where Work Stalls)

A team can accomplish a lot, but when work slows down in the middle of the process, overall delivery is affected. Bottlenecks occur when work items are waiting too long to be reviewed, clarified, or to be handed off between employees.

You can search for items that haven’t been updated for a while (e.g., more than 10 days ago), using a JQL query. For example:

project = MARK AND sprint = 34 AND status NOT IN (Done) AND updated <= -10d 

This helps identify work items that may be stuck, but JQL cannot determine how many times they were left with no attention or how long they waited in total.

👥 Ownership Changes

When the reassignment of work items is done excessively, the team becomes inefficient. Every hand-off is time spent in recovery, including clarification of requirements or context-switching. Monitoring ownership changes allows you to identify unclear responsibilities or team members who are overloaded and continually shifting tasks.

To get the work items where the assignee changed at least once during the specific sprint, you can use such a JQL query:

project = MARK AND sprint = 34 AND status NOT IN (Done) AND assignee CHANGED

But, in such a case, JQL has a huge limitation. It doesn’t show you who handed the task to whom or how many times it changed owners.

Unlike JQL, which simply indicates that a change occurred, the Issue History app captures all reassignments in detail.

You will be able to see exactly how ownership shifted, can filter transitions to and from a specific assignee, and export the list to identify tasks with too many reassignments.

🚨 Priority Changes

The priorities of the tasks have to be changed sometimes - there are urgent bugs or the needs of the customer change. However, when priorities change too frequently, the team will lose focus and spend time re-planning rather than delivering. Monitoring priority changes allows you to know whether planning is stable or unstable.

With JQL, you can search for work items where the priority was updated in a sprint:

project = MARK AND sprint = 34 AND status NOT IN (Done) AND priority CHANGED

However, JQL doesn’t show when it changed, how many times, or who changed it.

Issue History for Jira app keeps a record of every priority update. Using it, you’ll see exactly which work items had their priority updated, who changed it, and when. 

🧭 How to Use This Checklist

• Review it at the end of every sprint or every month.
• Use JQL to carry out quick checks of the current state.
• Use Issue History for Jira app to get the whole picture with filters and exports.
• Present the findings at the sprint reviews or retrospectives.
• Turn insights into actions: rebalance workload, reduce reopens, stabilize priorities.
  
  

👉 Don’t hesitate to try Issue History for Jira app to get a complete view of your team’s performance easily and fast.