List issues without sprints - moved issues not listed by JQL

[Romano Silva]

I have this particular use case:

Issue VBGA-9 was resolved in a given sprint. Once we realized it was not resolved properly, we reopened the issue. The sprint is now closed and the issue moved to the backlog.

I cannot find a JQL query to list this issue as not being in any sprint:

JQL: sprint not in (closedSprints())

JQL above does not work because the issue has a Sprint on its Sprints list as you can see from screenshot bellow.

Looking at resolution does not work as well as this issue has a resolution (even though it is still open). 

Looks like I need to rely on status category not done. Eventually I would like to query also closed issues without sprints for reporting.

It would be nice to have something like a "currentSprint" field which is not a list but the actual assigned sprint.

[Dave Menconi]

The part of your narrative that jumped out at me was the statement " this issue has a resolution (even though it is still open)" -- this is a workflow problem (bug). You probably need to fix this because Jira (in general) and Jira Software (agile specifically) doesn't do well with open issues that have a resolution set. 

By fix it, I mean both preventing it from happening in the future AND fixing all the issues with this problem.

For the first, go through every transition in the workflow to a non-closed state and add a postfunction that clears (set to empty) the resolution field. While your there make sure all the close transition SET the resolution to something (if it has a transition screen that's fine). All those postfunctions are a real pain but that's why they pay us the Big Bucks... 

For the second part, you need a transition for every open state that loops back to itself, clearing the resolution (if you use global transitions, you probably already have this). Now you do a bulk transition of all the issues that are open but have a resolution to the same status they are in. Keep looking for open issues with resolutions until you have them all. 

 

[Dave Menconi]

Sadly, my answer above doesn't address your original question (I hate it when that happens). 

I think the answer is to find all the issues that are OPEN and are not in an open sprint. 

To say "not in any sprint" doesn't work because an issue might have been in a sprint but, for several reasons, not closed in that sprint when the sprint was ended. 

I think this might work 

resolution is empty and sprint in openSprints()

(this assumes you fixed your resolution problem)

This might be too extensive (there should be 100s of issues in the backlog which will be shown up by this). Perhaps something like updated>startofweek() would narrow it down but the exact technique depends on what you are looking for. 

[Romano Silva]

I agree with you workflow argument.

The JQL you suggested, though, has the problem of not identifying resolved issues fixed "outside" a sprint.

resolution is empty and sprint in openSprints()

 Basically, I want to know all issues that:

1- are unresolved and not in a sprint - backlog

2- are resolved outside a sprint: this one would be easy if I did not have these "moved" sprints issues. I want to avoid closing issues without placing them in a sprint. Of course, this can happens - duplicates, for example, or issues that were side fixed. Anyway, I would like to report those.

[Dave Menconi]

Oh. Sorry, did the exact opposite of what you wanted. 

How about 

resolution is empty and sprint not in openSprints()

You might need 

resolution is empty and (sprint not in openSprints() or sprint is empty) 

at least that's what happens with labels (and sprints seems to me to be the same sort of field as labels).  

[Romano Silva]

I think the best approach here is actually having a custom field called "currentSprint" and I set/reset it everytime the sprints field is changed or issue is moved out of a sprint.

I found this : https://jira.atlassian.com/browse/JSWSERVER-12432 

Not sure if JQL allows something like:

resolutiondate > max(closeSprints().completedDate)

[Dave Menconi]

I don't like the idea of creating a NEW custom field which now has to be set and reset for every edge case. 

The problem you are having is because there are two custom fields (sprint and resolution) which are either not getting set properly or follow complex rules to accommodate complex edge cases. 

Creating a NEW custom field which will require its own complex rules (presumably implemented in project automation) to accommodate complex edge case sounds like just making the situation worse. 

I have no doubt it can be made to work but I wouldn't give up on the sprint field just yet. 

The problem you're running into is that "sprint" is a list of values (every sprint this issue has ever been in) and you want it to be the sprint it was closed in or the open sprint it's currently in. 

But, as I suggest above, I think the syntax of JQL gets you around this problem, just as it does with Labels.