How can JQL return current sprint and future sprints?

[Bud Herz]

Previous person wrote this JQL for a dashboard to display work from future sprints and the backlog. Note that it's hardcoded so the sprint numbers need to be updated every sprint -

"Team[Team]" = <team ID> AND project = FS AND sprint IN (348, 349, 350, 356, empty) AND type = Story AND status IN ("To do", "In Progress", "Dev Blocked", "In ST", "ST Blocked", "UAT Ready", "Code Review", "Ready ST") ORDER BY created DESC

I've been looking for something in JQL that might allow me to get away from that. Could I possibly use "AND Sprint IN openSprints()" then some sort of future sprint variable like "opensprint +1" ?

I know we can subtract dates. For example, I also have Global Automations to report the bugs opened and closed in the previous 24 hours using "AFTER -1d"

@Bill Sheboy  you seem to always have great ideas. Any thoughts? TIA

[Trudy Claspill · Accepted solution]

Hello @Bud Herz 

Jira does not natively support providing parameter input to the functions closedSprints(), openSprints(), or futureSprints(). Nor does it natively have additional capabilities for selecting issues based on associated sprints other than explicitly specifying the sprints.

Using sprint IN openSprints() will give you issues in all currently open/Active sprints where the issue match the other criteria in your JQL.

Using sprint IN futureSprints() will give you issues in all currently planned but not yet started sprints where the issue match the other criteria in your JQL.

Do you typically have only one planned sprint or do you have multiple planned sprints?

If you have multiples are you trying to get issues for just the "next" planned sprint? And if so, what information available for that sprint tells you it is "next" vs. any of the other planned sprints?

Do you have any third party apps that extend the JQL capabilities, like ScriptRunner? Are you open to considering getting an app if it would enable you to meet your requirement?

[Bill Sheboy]

Hi @Bud Herz 

Yes, and...to the suggestions from @Trudy Claspill 

When you want to include all future sprints, the JQL function Trudy notes will help.

When you want a subset of them based on specific criteria, you could use an automation rule to dynamically update the saved filter used by the dashboard, calling the REST API endpoint to identify the relevant sprints and another endpoint to update the filter...both using the Send Web Request action.

Kind regards,
Bill

[Bud Herz]

I hadn't refreshed to see these replies. Thank you @Trudy Claspill and @Bill Sheboy !

[Bud Herz]

@Trudy Claspill  - I believe we have ScriptRunner. I know we can use the - IN openSprints() since I use it frequently. 

I will try out the sprint IN futureSprints() to see if I can get what I need. 

To answer your questions:
We used to have only one sprint (the active sprint). We evolved to prepare a single future sprint maybe a year ago. Currently I am pushing to have at least three future sprints so we can forecast our future work better and leverage the Timeline view and Plan view.

[Matt Parks]

If you have Scriptrunner, you can use the following function to return any issues that are associated with the next, non-active sprint on a particular board

issuefunction in nextSprint(xxx) where xxx is the Board name or ID (if it's a board name, I believe you have to put it in quotes, but not for the Board ID).

[Trudy Claspill]

@Bud Herz 

closedSprints(), openSprints(), or futureSprints() are all native JQL functions in Jira. The do not require any third party app.

[Bud Herz]

Bill I see you had suggested the REST API for a similar question here:
https://community.atlassian.com/forums/Jira-questions/JQL-for-next-sprint/qaq-p/1821910

My challenge differs from that one I think because I hope to be more versatile by not using the sprint names. (Which is mentioned in that Q&A.)

[Bill Sheboy]

Looks like the JQL function worked for you, but to close the loop...

You wouldn't need the sprint names, only the board name to find the sprints...and then filter from there. The REST API approach helps when there are no issues assigned to the future sprints yet, AND one still needs the filter updated to specifically reflect the sprints.