Discrepancy/Difference in JQL queries?

[Dom Bogle]

Hi there I'm trying to work out why I have a discrepancy when looking up bugs in a project under certain statuses but excluding any bugs moved to a certain sprint board.

When I check on with this query for bugs in a retainer backlog sprint I want to exclude from my master list:

project in (x, xx, xxx) AND issuetype = bug AND status in ("In Progress", "To Do", blocked) AND sprint in (xxx)

I get 44 issues

However, when I try and add the equivalent sprint != exclusion into my main master list query:

project in (x, xx, xxx) AND issuetype = bug AND Status in ("To Do", "In Progress", Blocked) AND sprint != xxx ORDER BY cf[10020] ASC, created DESC, priority DESC, status DESC

I end up seeing a larger reduction of 55 issues (176 in list then reduces to 121 after the sprint != addition).

Not sure why there is a difference/discrepancy across the two queries but thinking it may have something to do with the JQL ordering in the list? Though not sure at all so thought best to post here in case anyone has come across something similar.

Thanks,

Dom

[Jack Brickey · Accepted solution]

I'm not sure I follow so bear with me...

in your first query, you are searching for issues that are or have been in a specific sprint, let's call it "Sprint Fred". The query returns 44 issues.

your next query returns excludes "Sprint Fred" and returns 121 issues.

you mention 176 issues. Can I assume that is the number of issues if you leave the sprint component out of your query altogether?

Remember that depending on your exact goal, you should consider an empty field. In other words "sprint is not empty" or "sprint is empty".

With all that said, if you are trying to make things add up, then as an example, you might use the following. Note for simplicity sake I just excluded a lot of her query conditions.

1. project =abc and sprint = "Sprint Fred"
2. project = abc and sprint != "sprint Fred" and sprint is not empty
3. project = abc

so...

The sum of issues returned from 1 and 2 should equal the number of issues returned by 3.

[Dom Bogle]

HI @Jack Brickey

Thanks for getting back!

Yes in the first query I'm looking for bug issues with the statuses of 'to do', 'in progress' and blocked that have this sprint field applied.

In the second query, I'm looking for bug issues across the project similarly with statuses of 'to do', in progress' and blocked but also want to add the opposite of the above query so as to exclude that total - i.e. (do not have this sprint field applied).

So I thought there shouldn't be a difference in the second query reducing by the amount of the first when the part in brackets is added. But I think you're right and that it must be doing something with empty fields as well when I add the 'sprint !=' addition and I maybe have to consider adding in more information to the query to allow empty sprints to show as well perhaps? That might then resolve the extra 11 that seem to be getting removed when I add this sprint exclusion in?

Thanks,

Dom

[Dom Bogle]

Hi @Jack Brickey 

Having now checked my larger filter and checked issues empty of the sprint field, they total 11. So that's what is throwing this exclusion off. I will work out a way to get any issues not in sprint and also without any sprint to be included within the one query.

Thanks again,

Dom

[Jack Brickey]

maybe this?

project in (x, xx, xxx) AND issuetype = bug AND Status in ("To Do", "In Progress", Blocked)AND sprint != xxx and sprint is not empty ORDER BY cf[10020] ASC, created DESC, priority DESC, status DESC