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 78 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.

[Gor Greyan]

Dears,

Sorry, the 48 should be 78.

Via this query, I have 78 tickets.
See the screens.

Also that sprint is future sprint, can it be the issue?

[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?

[Artem Nek_Votazz]

@Gor Greyan Thanks  — that's a useful clue, it definitely points at something rank-
related (visibility shouldn't depend on the Ranking toggle otherwise). I
just want to make sure I read the behaviour correctly, because a couple of the
details seem to point in opposite directions:

• With Ranking ON — is the issue visible or hidden, and what count do you
see?
• With Ranking OFF — visible or hidden, and what count?
• When you drag it into the sprint and it disappears — does it vanish only
from the rank-ordered board/backlog view, or also from a plain issue search
(Filters -> the same JQL)? If it still shows in the search, it's there,
just not rendering in the ranked view.

One thing worth trying regardless of the answers: in the backlog,
right-click the affected issue -> "Top of backlog" (or Bottom). 

That forces a fresh rank value onto it.

If it then stays put when added to the sprint, it was just a stuck rank
value and you're sorted. Stuck/missing rank values are a documented thing on DC; I'm honestly not sure Cloud behaves identically, since Atlassian
manages the ranking internals there. 

Best,

Artem

[Gor Greyan]

Dear @Artem Nek_Votazz

Thanks. Here's what I've confirmed so far:

• With the board filter containing ORDER BY Rank ASC, Sprint 135(444) shows 38 issues in the backlog view, and the affected issue (for example REL-24314) is not visible in the backlog.

• If I remove ORDER BY Rank ASC From the board filter, the backlog count increases to 74 issues and REL-24314 becomes visible.

• The issue is still returned by JQL searches in all cases, for example:

Sprint = 444 AND issuetype not in subTaskIssueTypes()

Returns 78 issues, including REL-24314.

I also removed it from the sprint, from the backlog section, and dragged and dropped it to the sprint, but the behavior did not change. And it disappears from the Backlog view.

Based on that, it looks like the issue exists and matches the filter, but is being excluded only from the ranked backlog view.