There's no JQL that can get it out of the box in JIRA Cloud, I'm afraid.
JQL does support some historical search operators (
CHANGED AFTER, etc), but these only work on certain fields. Unfortunately the Sprint field doesn't support these type of history searches.
Of course you can search for JIRA Cloud add-ons which expand search capabilities in various ways, but I'm not sure if you'll find something suitable.
Another option, although not exactly what you want, is the Sprint Health Gadget which shows sprint scope change %.
But don't those "View in Issue Navigator" links get all completed/not completed issues, not just those added after sprint start?
The "Issues Not Completed" list could be a mixture of issues added before sprint start and issues added after sprint start, as could the "Completed Issues", right?
The only way I found to identify the issues that were included in the sprint after the initial date was coordinating with my team to tag them as a "detractor" issue. How?
We created a dedicated "Component" named "Unplanned" and then, we made JQL filter to extract them after we close the sprint. Everyone committed to include this component in each unplanned issue during sprint period. The JQL is like this:
project = "My project" AND component in ("Unplanned") AND Sprint in closedSprints() AND resolved > -17d ORDER BY component ASC
Hope I could helped!
The workaround I use is to co-opt one of the fields that the historical (
CHANGED AFTER, etc.) operators work on:
We do continuous delivery and don't use the Fix Version field for planning releases, so I've created a Version called
Sprint Target there. At the end of our sprint kickoff I select everything in the sprint and add it to that Version. I can then do searches like
sprint = 'Sprint 27' AND fixVersion WAS 'Sprint Target' ON '2018-10-21' I mainly use that to color-code any issues that are added after the sprint start as different from the ones that are there at the beginning of the sprint so we can keep our eye on the ball.
It's annoyingly manual ad fiddly, and I agree with @Greg Wissler that just giving us JQL access to the data that's clearly already there would be way easier. But it does what I need reasonably well.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs