+1

+1

+1

+1

+1

determine what moved
determine which sprint it moved to

+1

Hi everyone, just till this ticket is resolved, you can try GO! JQL: Essential JQL Functions

Doc: https://almbase.atlassian.net/wiki/spaces/MDOC/pages/4100555652/Sprint+JQL+functions

Marketplace: https://marketplace.atlassian.com/apps/1225063/go-jql-essential-jql-functions?hosting=datacenter&tab=overview

@atlassian, Any update on where this stands?  This seems like a common sense feature

+1

Very useful

Please.

+1

+1

Although it wouldn't address ALL of the requirements here (especially in terms of ADDING) having the ability to do

sprint was in (sprintname) and sprint not in (sprintname) 

would be a good start here, especially because 

fixversion was in (fixversionname) and fixversion not in (fixversionname) DOES work as expected and has done for some time I believe.  

This is very useful feature to be implemented.

+1

+1
With the added requirement in our company that this should be useable for visualization on a scrumboard (for card colour or swimlane).

I have also just noticed that the Scriptrunner workaround seems to work (as it does not require hardcoding the current sprint).
But it is a little weird to me that Jira shows this only with asterisks in the sprint report and not on the board itself.

+1

Hello everyone, 

You can search the issues added to or removed from sprint after sprint starts with the GO! JQL plugin. It is for Jira Server and Jira Data Center. The Jira Cloud version will be released soon. Here is the [documentation|https://almbase.atlassian.net/wiki/spaces/DOC/pages/4028989441/Sprint+JQL+functions].

I hope it helps, bests! 

+1 What if we ask Pretty Please.. will that move this to the top?

+1

+1

+1

+1

Please bring this forward. We can really use this JQL!

+1

+1

This would be great!!

+1

yes please +1

If you have a user that just "Removed" an issue and didn't actually DELETE the issue, you can automate it. If the issue is put in the "removed" status, you can do one of the following:

1. Send an email to yourself when an issue in "openSprints" is put in the Removed status (you might even be able to do it if it is deleted but not sure about that) via automation
2. Send a slack instead of email
3. If #1 occurs, you could also immediately transition the story to either the backlog OR the current sprint and add an "Attempted Removal - " at the beginning of the Summary.

*I have done this successfully on a Kanban board if someone removes an issue after it has been started, regardless of current status. I know the same can be done using sprints.

MY issue is I need to know if someone removes a specific label and be notified when that occurs.

I figured out that you can use fieldChange.fromString and fieldChange.ToString for my issue. It is possible a variation of this can help the OP's issue.

+1

+1

+1

+1

This is so needed

+1 

And agree, we shouldn't have to prove a need if it's a common use functionality that should be available anyways!

+1

+1
Info is already presented in the report. 
Please provide the same info via JQL to be imported to the Confluence page.

+1

Clearly, everyone wants this.

How much more interest is needed to demonstrate the impact of this relatively straightforward request?

+1 

+1

+1

+1

+1

As Agile Coach, this is a key concept to be tracked in order to get usefull metrics for any team/organization. It is impossible to get real metrics based on "all issues" added to a sprint instead of all issues the team "planned/confirmed/committed" to do in the sprint. It is also very hard to get all issues that was "finished/validated" in that sprint (because they can be moved along different sprints in their lifecyle, even when it is not the desired case).

I can't understand how Jira use that data in so many graphs, reports and tables but it is not exposed even in the database for mining them.

Thank you for taking this into consideration and making all organizations more agile, flexible and actionable!

+1

+1

+1

+1

+1 from me as well. Please don't force us to abide to the paradigm of not moving tickets out of Open Sprints - sometimes we are interested in what moved in/out of Open Sprints as well, not just by what went in/out of Started Sprints.

+1 as should exist!

+1 as should exist!

+1 as should exist !

+1 yes please with both JSWSERVER-20097 & JRACLOUD-75868) to add the feature to JQL like mentioned in Ricardo's prior comment

+1 please, this information has been removed from the reports section.

+1 please add this <3

+1 as should already exist !

Adding a Vote for this new feature. We cannot have all the add ons. Thanks

Please, add this feature. It could be super useful to keep track of the sprint status and right now we can only make workarounds.

+1

Is there an update here? Per the ticket's history, looks like there's been interest gathering/building for over 2 years now despite the obvious voice from the user base demonstrated just here

+1

Please add this feature

This would be really useful. Please try to provide the solution asap.

Thank You

+1 on having this implemented in JQL. It will surely make life easier.

This would be really useful. But I retire in seven years, so I'll probably be disappointed.

I would like to vote for having this feature implemented in JQL

+1 to Ricardo's comment

Perhaps a good solution here would be to use the same functionality Jira already uses on the Sprint report page by providing the following JQL functions to users:

• Issues Completed in Sprint
• Issues Not Completed
• Issues Removed from Sprint
• Issues Added to Sprint (the ones marked with "*")
• Issues Completed Outside of the Sprint

With these functions, you could easily do things like this:

project = ABC AND issuesRemovedFromSprint(openSprint()) 

OR

project = XYZ AND issuesCompletedInSprint("Sprint 21") 

AND so on...

I am sure a lot of reporting issues would be solved If these were available as JQL functions. Besides, it shouldn't be difficult to implement since these are already implemented - it'd be simply a matter of making the JQL available. There are actually Jira plugins out there that already provided these functions, which is what pisses most people off... Vendors ahead of Atlassian on something that should be out-of-the-box functionality that they're obviously charging for.

This is a MUST have JQL functionality that I'm really surprised Atlassian hasn't made available so far.

Without it, it's impossible to manipulate sprint tickets data and produce accurate reports. We're creating our own KPI tool extracting data from Jira via JQL but not having a way to differentiate tickets that roll in and out of the sprint are a huge show-stopper for us.

Please add this feature so that it doesn't require an add-in.  Great feature to visualize on boards and dashboards!

I also need this feature.

Sprint churn is a viable metric for the health of the team/process and measuring improvement efforts.  The two simple components of churn are:  number of issues added after the start of the sprint and number of issues removed after the start of the sprint.  Clearly Jira has the ability to determine the information as it is visually displayed on the Sprint report.  We are just asking for the same information to be available using a JQL statement.  Ideally, wildcard (like Active Closed) and Sprint Range options would be available.  This feels like an out of the box functionality miss that has immediate benefits to the team by providing transparency into the process.

Also, Scriptrunner's solution has limitations in that you can only specify a single sprint value or the active sprint (if no value is entered).  If you are looking to determine a trend you have to look at each closed sprint individually.  You probably could create a script to parse the closed sprints but the average user is not going to have that kind of access or ability. 

a fundamental feature in my eyes.
Suggesting Apstavist Scriptrunner as a workaround sounds like using a sledgehammer to crack a nut (we won't have/use it)

Are you kidding me, this is not an available feature?

I was able to find it on reports at one point, but Jira reports are like the stairs at Hogwarts.

building this functionality would be immensely helpful.

This seems like a fundamental gap that should be prioritised for delivery. 

HOw does one know someone at Atlassian is looking at this thread? Can we please get this done? 

@Isaac Jones

I share your pain and one workaround I am using is to just mass update all committed issues with label "plannedXY" where "XY" is the sprint ID. 

Then I have a filter for card colors setup based on JQL where one condition is this:

"labels not in (plannedXY, unplannedXY) or labels is EMPTY"

• this JQL can be used for card colors as well as for any other purposes

I am adding unplannedXY label daily after I have made sure that developers are aware of the new issues in sprint and just before I end the sprint.

... hope this helps someone until Atlassian finally catches up with this seemingly rudimentary requirement.

+1 could we get this sorted please? Finding the asterisk on the burndown chart it's really not that helpful.

My use case is slightly different. I would Like output to be a boolean that can also appear in issue search exports, which we use for data processing. Currently, I have to manually go and note which issues have an asterisk beside them on the reports page to know what was committed and what wasn't. Another benefit would be to use this for Card Colors, to indicate which Sprint Backlog items were brought into the Sprint.

Same comment as @Season Hughes and @Carsten A. above.  We want to color the card differently in the Active sprint so developers will know to work on the commited issues for the sprint first before working on other issues that were added after the sprint started.  Alternatively, if you can just tell others to stop adding issues to our sprint after it starts, that would work too. 

When we start a development sprint we commit oursevels to a sprint goal.

However when for example a lot of bugs are submitted, that have to be done ASAP it may jeopardize that goal. To be able to see that coming early before it escalates, we would like to add gadgets to our teams dashboards, that show (preferably something visually like the created-vs-done gadget) easily how many tickets were added to the active sprint(s).

Therefor we need a JQL function that not only somehow shows issues added to an active sprint after start but also a JQL function to be able to highlight such issues in our Scrum board swimlanes.

Our team also has a workflow around pulling stories into the Sprint and would like an easy way to highlight them on our Sprint board. Jira has functionality to put an asterisk next to these on the Sprint report, and I would like to do a jql query to filter them into a swimlane on our Sprint Board.

Our teams would be greatly helped with this JQL addition as we have a strict workflow policy on handling issues that are committed up front versus those added while mid sprint. E.g. testing is to be done on committed stories first. The teams now have to constantly switch between reports and/or manually add labels to have this distinction visible. This is very labor intensive and error prone.

So a big +1 for me and all other POs and SMs on this request.

Eerk Hofmeester, Sanoma

This would be really useful also for statistics and dashboards, it could be also something simple like a date, when an issue has been added to a sprint, so that you can write a query like "dateAddedToSprint > sprint.startDate and dateAddedToSprint < sprint.endDate". But I think it would much easier if Jira just marks all the issue added to a started sprint, so that it would be enough to query "addedToStartedSprint = True"

My interest in this is because I wanted to have a query I could paste into a Jira macro in Confluence, something to count tickets added to a specific sprint after it started.