Issue Count Inconsistency in Backlog and In Issue Search

[Gor Greyan]

Hi Dear Community,

I have the following issue in my Jira Cloud.

I have a company-managed project and a Scrum board.

This is the Query for the Board Filter

project = REL and issuetype not in (Design) ORDER BY Rank ASC

And when searching this JQL, it returns 48 tickets.

Sprint = 444 AND issuetype not in subTaskIssueTypes() and issuetype != Design

But in the Backlog view, the sprint 444 is showing just 38 tickets.

Could anyone suggest a solution?

There is no filter set in the backlog view.

[Germán Morales _ Hiera]

Hi @Gor Greyan 
The backlog only counts issues that match the board's filter and sit in that sprint. Your search query has no project = REL clause, so it's pulling sprint 444 issues that the REL backlog deliberately leaves out. Those 10 aren't missing, they just fall outside the board filter. Put the board filter and the sprint clause in one query and the counts should line up:

project = REL AND issuetype not in (Design) AND issuetype not in subTaskIssueTypes() AND Sprint = 444

If that lands on 38, the dropped scope was the whole story. If it's still above 38, the leftover issues have 444 sitting in their Sprint field next to another sprint, since that field is multi value and keeps past sprints once they've been completed. Add the Sprint column to the results and check each row: anything whose current sprint isn't 444 is one of those carry overs, not a true member of 444.

Atlassian describes this same check (the board's filter query combined with Sprint = <id>) here: Some sprints are missing from Agile boards

[Arkadiusz Wroblewski]

Hello @Gor Greyan 

Just to add one small easy check to @Artem Nek_Votazz  answer....

Run the exact JQL query with your board filter included:
project = REL AND Sprint = 444 AND issuetype not in subTaskIssueTypes() AND issuetype != Design ORDER BY Rank ASC

Next, add Project, Sprint, and Status as columns in your search results view.

If the count drops from 48 to 38, the discrepancy is caused by issues falling outside the board's specific filter criteria. If it still shows 48, check the Sprint column closely; some issues might hold Sprint 444 as a historical value while currently belonging to a different active sprint, which explains why they match the JQL but are missing from that specific board's backlog.

Play a little with that, you should find fast what causing it.

Best,

Arkadiusz🤠

[Artem Nek_Votazz]

Without seeing the actual issues I can't say for certain, but a count like
this
almost always comes down to one (or both) of two well-known behaviours —
the
board/backlog and a raw JQL search just don't count the same way.

A board's backlog only shows issues that (a) match the board's filter and
(b) have that sprint as their *current* sprint. Your JQL is constrained by
neither fully, so here are the two likely causes:

1) Possible cause — the board filter is scoped to project = REL, your JQL
isn't.
The board/backlog only ever shows issues matching its filter
(project = REL AND issuetype not in (Design)). Your JQL drops project =
REL,
so it may also be counting Sprint 444 issues that live in other
projects/boards.

2) Possible cause (and often the bigger one) — the Sprint field is
cumulative.
When an issue moves from one sprint to another, Jira keeps the old
sprint
value on it (by design, to preserve sprint history). So Sprint = 444 can
match issues that were *ever* in 444, including ones since moved to
another
sprint or to the backlog. The backlog lists each issue only under its
*current* sprint, so something that went 444 -> 445 would still hit your
JQL
but show under 445 in the backlog.

A couple of checks to see which one it is:

• Add the project clause and re-run — if it drops to 38, cause #1 explains
it:
project = REL AND Sprint = 444 AND issuetype not in subTaskIssueTypes()
AND issuetype != Design

• If it's still ~48, add the "Sprint" column to those results and look at
each
row's current sprint — any showing a sprint other than 444 are the
cumulative-
field case (#2).

Both are expected behaviour rather than a bug — the backlog reflects what's
currently in sprint 444 on this board, while the raw JQL is broader.

[Gor Greyan]

Dear @Artem Nek_Votazz

Thanks for your answer.

I found a specific thing.

When Ranking is enabled, my mentioned issue is visible. Backlog shows 38 tickets.
When I am disabling Ranking, the ticket count in Backlog is okay.

When I am removing the ticket from the sprint, it is visible in the Backlog. I am dragging and dropping it to the sprint, and it is being disappered.

Any suggestion on this?