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 .
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
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:
Hope it will be useful!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
Do give it a try.
Disclaimer : I am part of the app dev team
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.