nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

I want to find out all bugs that a developer resolved in a particular release using jira query .

Abhisek_a38d7z

generally a bug is assigned to a developer; once the developer fixes the bug, it is assigned to the qa for testing. so if i use developer name in assignee as part of jira query, it will not give me the result. so i want to know, how to find out all tickets that a developer works on a particular sprint or release using jira query or any other way .

Accepted answers

All comments

Arkadiusz Wroblewski

Hello @Abhisek

With Marketplace apps you have more options than with native JQL alone. At some places JQL are just limited and we must live with it.

Especially apps for issue history / time in status / enhanced JQL can help here, because native JQL can tell you that a bug was assigned to a developer, but not always reliably that the developer actually resolved it after QA reassignment.

Tools in that area are for example JQL Search Extensions, Status Time Reports / Time in Status, or reporting apps connected to Power BI / Tableau. These can usually analyze lifecycle/history data much better than standard Jira reporting.

Just take a look at the Marketplace, get a trial version, and see what helps you.

The important part and Trap is even with an app, exact “resolved by” reporting is best when that value is explicitly stored in the process, for example via workflow or automation.

Benjamin_tmh9yg

HI @Abhisek ,

You can use the was operator to look for issues that was assign to the developer.

JQL = assignee WAS "john.doe" then you can add the particular release or sprint in the JQL to narrow down your search. Ideally, the task should be by one assignee. Now, you can use Teams in cloud. Especially, this would be use for when assignee is out and requires someone to step in from the same team. 

Hope this helps.

Bill Sheboy

Hi @Abhisek

For the Assignee field, the built-in WAS IN operator could be used; then add your other criteria by Sprint, Fix Version, etc.

For example, to find work items to which I was assigned in the current sprint:

project = MYPROJECT
  AND assignee WAS IN ("Bill Sheboy")
AND sprint IN openSprints()
ORDER BY Key ASC

I used the WAS IN operator so my display name could be preserved without it converting to the user ID value.

Please also see the JQL functions to help with the other criteria.

Kind regards,
Bill

Bartek Szajkowski _ Orbiscend OU

Hello @Abhisek

Hope my answer meets you well.
I'm Bartek from Orbiscend OU.
If you are open for try third-party app as Arkadiusz proposed, I could recommend check Argon powerful JQl Search app.

ARGON Powerful JQL Search

Argon can help with this using the transitionedBy function — which tracks who moved an issue to a specific status, regardless of who the current assignee is.

Even after a bug is reassigned to QA, Argon remembers who transitioned it (e.g., moved it to "In Review" or "Done"), which is typically the developer who fixed it.

Example:
Find all bugs a developer resolved in a specific date range (e.g. a release window):

issuetype = Bug AND issue in transitionedBy("project = DEV", "Done", "2024/01/01", "2024/03/31", "john.smith")

Hope my answer will be helpful for you.

Greetings
Bartek from Orbiscend OU

Natalia_Kovalchuk_SaaSJet_

Hi @Abhisek !

You can't do this using only JQL, as it can show only the current assignee and the current task status.

To find out which bugs a developer worked on in a specific sprint, you need to check the change history. One way to do this is using apps like Issue History for Jira (Work Item History) by SaaSJet team. With its help, you can filter the tasks by sprint and by specific assignee (developer).

So, using this app, you can:

filter bugs by sprint and by developer
get a clear list of bugs a developer actually worked on (even when they were reassigned to QA).

Hope it will be useful!

Bill Sheboy

Hi @Natalia_Kovalchuk_SaaSJet_

Regarding your comment:

You can't do this using only JQL, as it can show only the current assignee and the current task status.

That is not correct, as the WAS IN operator in JQL works with the Assignee, Status, Fix Version, etc. to provide this information. It does not work with the Sprint field, although the DURING operator could be added with a date / time range to answer that part.

https://support.atlassian.com/jira-software-cloud/docs/jql-operators/#WAS-IN

Kind regards,
Bill

Rahul_RVS

Hi @Abhisek

You can use Jira Rest Api's to pull this information and build your own custom solution.

However if you need detailed reporting to track changes for multiple issues, you may want to have a look at a mktplace app for the same.

We have built an app to extract changelog data in a simple and easy to use interface. The data can be exported to a CSV file as well.

It provides complete details of who changed the data, what was changed and when.

Issue History Reports

Do give it a try.

Disclaimer : I am part of the app dev team

Issue History.PNG

Natalia_Kovalchuk_SaaSJet_

Hi Bill Sheboy!

Thanks for such a clarification. Yes, you are totally right that it is possible to use the WAS IN operator in JQL.

What I meant is that when you run a query like assignee WAS IN (...), the Assignee field still shows the current user, not the one who worked on the task earlier.

For example:

Frame 624669.png

It can be a bit confusing.

That’s why I mentioned Issue History for Jira (Work Item History) from my team, as it helps easily filter tasks by sprint, see all status and assignee changes, and quickly find which bugs a developer worked on, even if they were later reassigned to QA.

Kind regards,
Natalia

Bill Sheboy

Thanks for your explanation, @Natalia_Kovalchuk_SaaSJet_ and, I do understand how the Jira work item history works. Including many of the defects and limitations in that history and its presentation in the UX.

While your app apparently helps visualize the history, the original question seems more aligned with a single person / developer's assignments, regardless of to whom the work items are currently assigned.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud