The question was already raised here by Ingrid and Sarah: https://community.atlassian.com/t5/Jira-Software-questions/Issues-do-not-appear-in-my-backlog/qaq-p/352913#M17450 According to Atlassian's documentation: "An issue will only be visible in the Scrum backlog if: (...) the issue's status maps to one of the board's columns" (from Using your Scrum backlog) I think this is a problem. Here is my use case: * In my workflow the initial status is New ( which means "undiscussed" ) * After New comes To Do in the workflow ( which means "we're gonna do it" ). * We are using Scrum boards and doing sprints. * The first relevant status of our sprint is To Do. * Thus the first column of our sprints is mapped only to To Do. * I don't want to see New issues in the sprint. * But I want to see New issues in the backlog. Because of Jira's limitation, if I want to see the New issue in the backlog, I have to map the status New to one of the Scrum columns. I don't want to do that. Am I the only one to want to organise my projects this way and thus to have this problem?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why must we map a given status to a column in order for the issue to appear in Scrum backlog?

David Roulin

The question was already raised here by Ingrid and Sarah:

https://community.atlassian.com/t5/Jira-Software-questions/Issues-do-not-appear-in-my-backlog/qaq-p/352913#M17450

According to Atlassian's documentation:

"An issue will only be visible in the Scrum backlog if: (...) the issue's status maps to one of the board's columns"

(from Using your Scrum backlog)

I think this is a problem.

Here is my use case:

In my workflow the initial status is New ( which means "undiscussed" )
After New comes To Do in the workflow ( which means "we're gonna do it" ).
We are using Scrum boards and doing sprints.
The first relevant status of our sprint is To Do.
Thus the first column of our sprints is mapped only to To Do.

I don't want to see New issues in the sprint.
But I want to see New issues in the backlog.

Because of Jira's limitation, if I want to see the New issue in the backlog, I have to map the status New to one of the Scrum columns.

I don't want to do that.

Am I the only one to want to organise my projects this way and thus to have this problem?

Accepted answers

Scott Theus

Hi @Thomas Schlegel!

Some Scrum Masters and Product Owners separate the Product Backlogs and Sprint Backlogs during sprint planning; the product backlog contains all of the stories in the project. During sprint planning, the PO selects the stories for the next sprint and then moves them to the sprint backlog. The Scrum team then writes sub-tasks for each story where needed, and the set of stories and sub tasks becomes the sprint backlog.

I've found that this setup gives more autonomy to the Scrum team; it allows the PO to set WHAT will be included in the sprint, while the Scrum team defines HOW the stories will be developed. It can be tough to get used to, but I've seen it work.

@David Roulin,

I suggest having two boards in the project; a Kanban board with all the current Scrum board columns, plus the "New" column, and a Scrum board with just the current Scrum columns. The Kanban board becomes your product backlog, During story grooming or sprint planning you can review the "New" items in the Kanban board and move them to the "To Do" column. All the stories that are marked "To Do" will show in the Scrum board as the sprint backlog.

Does this help?

-Scott

All comments

David Roulin

Simple suggestion: why not having a "backlog column" in Scrum boards too? (just like in Kanban boards)

Thomas Schlegel

Hi @David Roulin,

a backlog is meant to include issues that have to be done in a sprint (and which are ready to be done within a sprint).

So, if your "new" status is something, that has to be discussed yet and it is not even clear, if issues in that state will ever be done, they should not be part of the board. If the discussion is part of a sprint, it should be included in the board.

Your backlog is the source of issues for the sprints. And therefore, every status in the board has to reflect an issue status in your sprint.

I would not include the "new" status in the board. Manage the discussion status on a dashboard instead.

David Roulin

I see. In other words, I cannot have my project backlog in a Scrum board, only my sprint backlogs?

Thomas Schlegel

What's the difference between a project backlog and a sprint backlog? A sprint backlog is, in my opinion, the part of the project backlog which is added to a sprint.

So, the backlog is the project backlog. But part of the project is, to get back to @David Roulin's question, also the discussion about new issues. And if this is not being done within a sprint (which is totally normal, I think), it should not be part of the board.

Scott Theus

Hi @Thomas Schlegel!

@David Roulin,

Does this help?

-Scott

David Roulin

Hey @Scott Theus, yes this is more or less what I did.

One of our workflows allows undiscussed issues to be injected at different steps (concept art sprint, dev sprint, etc).

So we now have a "discussion" dashboard that lists all these new issues as @Thomas Schlegel suggested, but also a "planning" kanban board allowing us to graphically move those issues to the various initial sprint statuses.

David Roulin

I see your point. I guess it's a matter of scrum implementation glitch... erm I meant flavours :-)

See my detailed answer to @Scott Theus

Thanks for your help!

gabriel-franzoni-ifood

Although this works, this far from the best solution. Too much bureaucracy for a simple thing.

Nic Brough -Adaptavist-

Eh? You put a status in a column. I don't see how that is "too much bureaucracy" when the principles are explainable in a short sentence and it's a single action.

Aaron Stichter

I had the problem where my Sprint was empty/done and all my issues are in the Backlog. So when I am looking at the Backlog screen there is a sprint with no issues in it and I believe it said Start Sprint still. I was in the habit of working from the Backlog in this project and when I changed one of the issues in the Backlog to Testing status, it was disappearing from the Backlog. So it was hidden and forgotten.

This thread helped me solve my problem. I went to the Board Settings and found Testing was in the uncategorized column. I created a new column for Testing and dragged it into the new column. Then, when I went back to the Backlog the Testing issues were still hidden, even after reloading the page, so I was concerned the fix did not work and there is another problem.

After some experimentation I found that if I moved issues into a Sprint, hidden issues were all exposed in the Backlog. Hope this helps others.

Dorota Gut-Knapik

It seems the route cause is the category of the status which does not match the category of the column in the Active Sprint (board Configuration).

Example case

Status Deferred (yellow) is mapped to column Done (green) that stores all final statuses.

Issue type Bug in status Deferred is not visible on the Agile Board.

Workarounds

Option 1

To create a separate column on the Agile Board e.g. Deferred in a yellow category and map a Deferred status to this column.

Issue type Bug will show up in the Backlog.

Option 2 (I personally do not recommend)

To create (use existing) separate Agile Board with filtered all issues that are in the Deferred status but not assigned to any sprint.

However, my experience with the Agile teams shows that people prefer to have everything in one board, so they may forget checking other places. It will result with not planned/ completed issues.

Option 3 (I personally do not recommend)

To assign all Deferred issues to the sprint under the current Agile Board.

However, it requires:

prior planning and careful monitoring of Deferred items. Therefore you have to have a filter, dashboard or a separate board to monitor it anyway),
creation of "a dummy" sprint which will work as an another backlog. However, this proceeds to the confusion in a team and in my opinion – is not in line with the SCRUM methodology. In this case you also have to closely monitor of unassigned items (in a separate filter, dashboard or agile board).

Rabbit

Seconded.

geoff hoffman

I have some issues that show up in the backlog and some do not. When I create new issues, Jira alerts me: "Created <ISSUEKEY> but it's not visible" - Even when on the backlog, viewing the backlog, and using the Ajax-mini Create Issue plus-sign line-editor at the bottom of the backlog. It makes no sense whatsoever that I would have a dozen items in the current sprint, another dozen and a half items in the backlog, and new issues I create to put into the backlog are invisible unless I search for them. The status of the ones that show fine are "Backlog" as well as the status of the ones that are invisible. They're both Backlog and should both be in the Backlog.

As a user of Jira, I should be able to expect that issues with the status of "Backlog" display in the backlog. Is this too much to ask? The amount of arguing and discussion about this is just insane. This always used to work fine for unmapped columns on scrum boards when viewing the backlog.

The "Backlog" view does not appear to have its own "Edit Board Settings" - there appears to be only one Edit Board Settings and it only is for modifying the swim lanes. The Backlog pane, page or action, was always about viewing stories in the project backlog. This is now broken for me in at least one of my projects and I have to use JQL on the Issues screen to see newly-created issues "in the status of Backlog".

Rabbit

So, I've been content with this, but there's another problem-- cumulative flow diagrams. Everything in both the backlog and the todo/defined statuses shows up as 'to do' for the purposes of a sprint board's cumulative flow diagram, using this method. This throws off the ability to accurately report on backlog health, and also work accepted into a sprint.

I like the CFD's showing things by col, rather than specific status, but this is a real issue.

Adam Marshall_wlnlbx

My goal is to reduce the number of columns in the board and ensure that users do not work on items which are not yet approved. I cannot achieve this by mapping statuses to a single column.

A separate board works but is quite painful as it adds extra clicks all the time for users flipping between the two boards.

I'm trying to set up an approval workflow where when a user adds an item into a sprint it is transitioned to a new status and an approver field is populated. This would become very difficult as you would have to drag it into the sprint in one board, and then switch to another board to see it alongside the other issues.

It would be much better to show the issues in backlog view, and hide them in sprint view.

Anyone who wants to hide them in the backlog view AS WELL could simply edit the filter query for their board to exclude those statuses instead, but there is no option for those who want to include the issues in the backlog but not on the board. It confuses things because the filter query can conflict with the mapped statuses.

Johnny FromCanada

Jira is basically an issue-filtering mechanism - i.e., subtractive (additive is still possible, but more painful).

As a workaround (to many Jira phenomenon), for many years I have used Quick Filters (which are per-Board) to subtract out issues I do not want included, based on whatever matters to me, including statuses, issue types, and marked outliers (custom field). I use a naming convention that prefixes with '-' (minus symbol).

Many reports (which are also per-Board) allow you to invoke Quick Filters, case in point, CFD report.

So, in your case, you could create a Quick Filter on your Board that subtracts out the statuses you do not want to see, e.g., "-Backlog". Then on the CFD report select that Quick Filter under "Refine report" dropdown dialog.

Jetalkumar Desai

Swimlanes are for active sprint and backlog is to plan the work.

Swimlanes configuration should not impact your board data, that is stupid by design and lack of oversight. I am surprise not looked at it for 2 years. That is not common with Atlassian.

Thanks

Nic Brough -Adaptavist-

No, they're not.

Swimlanes are for grouping issues by something across the board.

They do not "impact your board data", and there's nothing "stupid by design" in swimlanes.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud