Backlog Issues Missing from Scrum Board

[Mike Landers]

I have a scrum board where there are only 24 issues shown on the backlog page, but advanced filter search shows around 150 issues in the backlog of this project. The board filter for this project is very simple: Project = DevOps, Type = All, Status = All, Assignee = All.

However, on the board settings page under Filter, it reports: "Some issues in the Saved Filter will not be shown on the board. View unmapped statuses which contain these issues."

The unmapped status is backlog. Isn't this normal? I don't want to show the backlog as a column on the scrum board because the backlog isn't part of a sprint. Am I required to map the backlog as a column to fix this issue or is there another way?

[Mike Landers · Accepted solution]

I think this is actually a weird bug because I tried mapping backlog issues to the To-Do column, and then all of the missing backlog issues show up on the backlog view. Since issues have to be assigned a value in the Sprint field to show up on the sprint board and backlog issues aren't generally assigned to a sprint, this bandaid/fix has no visual impact on the board (good).

[Trudy Claspill]

Hello @Mike Landers 

Welcome to the Atlassian community.

This is functioning as designed.

For an issue to be included, either in the Backlog screen or the Board screen, the status of the issue must be mapped to a column in the Board Settings > Columns configuration.

For a Scrum board it is not the Status of the issue that determines where it displays (Backlog screen vs. Board screen). Rather it is whether or not the issue in included in an Active Sprint. The Board screen shows only the issues in Active Sprints. The Backlog screen shows issues in groups per sprint (Active or Planned) with the remainder in the section of the list labeled Backlog.

An issue can technically be in any status and be in either the Backlog section of the list or in a sprint. The only exception is that issues in statuses mapped to the right-most column of your Board will not be displayed in the Backlog section of the Backlog screen. The Backlog section is for issue that are not yet "complete" and the statuses mapped to the right-most column are considered "complete", so there is no point in displaying issues in those statuses in the Backlog issue list.

[Walter Buggenhout]

It is not a bug, @Mike Landers, it is the way a scrum board and the scheduling of sprints works. See my answer for more details. 

[Mike Landers]

@Trudy Claspill @Walter Buggenhout Out of curiosity, why would it be intended to force users to map backlog issues to an existing scrum board column (columns are part of the active sprints view) if they don't want backlog issues to be displayed at all anywhere in the active sprints view? If I only want backlog issues to show up in the backlog view, there is no logical relationship between backlog issues and the concept of scrum board active sprint columns. The end result is functionally correct, but the way to achieve it seems totally illogical. Also, I can't think of a use case why anyone wouldn't want their backlog issues to show up in the backlog view. What is an example use case where a user doesn't want to see their backlog issues in the backlog view?

[Trudy Claspill]

@Mike Landers 

Please see my previous reply.

Jira's design for Scrum is such that Status is not the attribute used to indicate an issue in "in the backlog" vs. "in an active sprint'. It is the assignment of the issue to the Sprint and the Active status of that sprint that determines that the issue will be displayed on the board of Active Sprints.

The Backlog screen is another view of issues that covers the "backlog" (not-done issues not currently assigned to a sprint), issues assigned to future sprints, and issues assigned to currently active sprints. 

[Leo Petersen]

Conceptually, in scrum, backlog items are pulled from the product backlog into the sprint backlog, during sprint planning. It follows than any given backlog item, at any given point in time, exists only in either the product backlog or the sprint backlog. No backlog item can exist in both the product backlog and the sprint backlog at the same time. Therefore, in Jira, I cannot understand why a product backlog item should not be shown in the backlog, unless it's assigned a status that's mapped to a column of the scrum board, and therefore, conceptually, on the sprint backlog. 

So therefore, kind feature request:

For those of us who are thinking in "pulling backlog items from the product backlog into the sprint backlog": Make it possible to show backlog items in the backlog, even if they're not assigned a status that's mapped to a scrum board column.

[Trudy Claspill]

Hello @Leo Petersen 

As this is a user community and not the best way to communicate directly with Atlassian, I suggest the following options:

1. If you use a paid subscription have your Jira Administrators submit that change request through a support case at https://support.atlassian.com/contact/#/
2. Use the Provide Feedback option under the Help button next to your avatar within Jira.

[Rafa]

> why would it be intended to force users to map backlog issues to an existing scrum board column (columns are part of the active sprints view) if they don't want backlog issues to be displayed at all anywhere in the active sprints view?

Because atlassian is terrible at User Experience design and their wording and "logic" makes no sense unless you read their (often conflicting) documentation and are aware of their internal mental model of every little detail. 

[Walter Buggenhout]

Hi @Mike Landers and welcome to the Community!

Yes, you need to map the backlog status to the first column of your board. If you don't, your issues won't appear in the backlog of your board - as the message says.

Issues in the backlog will not appear on the active sprint unless you specifically put them in a sprint. Sprints, in turn,, have nothing to do with the statuses of your workflow. They are time slots that you create to schedule the work for an iteration. Once you start a sprint (from the backlog view) the issues in that sprint (and only those) will be displayed on the active sprint board, while all the others remain in the backlog. Until you complete the first sprint and start a new one with new issues from the backlog in it.

Hope this helps!

[Chestnut_ Sharon]

I have the same concern as @Mike Landers but for an additional reason. I am trying to use the "dots" on the active sprint card to see how long an issue has been in a status during the active sprint. But because we are forced to add what I would consider statuses only for the backlog, into our first column, the dots also reflect the time for those statuses as well. So for example, if I have the following statuses in my first column:
New
Groomed
Ready to Start

all 3 of those statuses are tallied together to reflect the dot count on an active card in my sprint. I may create a story (New) 3 weeks in advance, clean up the story a week prior to sprint start (Groomed), refine and estimate the story with the team, the day before the sprint (Ready to Start). All 3 would take ~3 weeks. the dots on a story that goes through that flow, shows it has been stuck in that column for 3 weeks when I only care about how much time it has stayed in a column during the active sprint.
Why do we no longer have a backlog bucket on our configuration page that allows us to keep New and Groomed in there and keep our fully refined and ready to be in a sprint stories in the first column?

[Trudy Claspill]

Hello @Chestnut_ Sharon 

Welcome to the Atlassian community.

The "backlog bucket" has been available only in Kanban boards, not Scrum boards. And setting the  backlog to correspond to specific statuses is available only for Company Managed projects, not Team Managed projects.

If you don't want the time in the New Status to be counted in a particular column, put those statuses in a different column. Perhaps not the left most column since that one is used to create the Estimate sum in the gray lozenge above each sprint.

You could label the column "don't use". You could also customize the workflow to limit who can transition issues into those statuses from the other statuses on the board.