Why is my backlog always invisible?

[Peter Cornelius]

I want three simple things: 

1) I can see work planned for all current and future sprints. 

2) I can see the backlog

3) I can see the roadmap, but epics are not visible on the sprint board. 

Right now the backlog is always empty. No matter what I add to it, the issues are hidden. I can find them, but they are never displayed in the backlog view. 

It's a scrum project. 

Let's focus on 1 and 2. 

This is driving me nuts. I can't wait for your help!

[Trudy Claspill]

Hello @Peter Cornelius 

Are you using a Team Managed project or a Company Managed project? It will say at the bottom of the navigation pane on the left.

Are you using a Work Management (aka Business), Software, or Service Management project? It will say at the top of the navigation pane just below the project name.

If you are using a Company Managed project, can you show us the board filter from the Board Settings > General screen?

If you are using a Team Managed project, do you have the Backlog and Sprint features turned on under Project Settings > Features

[Peter Cornelius]

Hello! 

It's company managed. I am the jira owner at the company though. So with some guidance I can make it whatever it needs to be. 

I am, not sure the filter is all that relevant. We've tried countless combinations of opensprints(), futuresprints(), backlog etc. But I'd love to be proven wrong and level up my JQL. 

project = QUELL AND issuetype in (Epic, Spike, Story, Task) AND status in (Backlog, Blocked, Done, Fixed, "In Progress", "In review", Rejected, "To Do") AND Sprint in (21, 22) ORDER BY priority DESC, Rank ASC

Thank you for helping

[Trudy Claspill]

Because you have included Sprints as part of your criteria, you backlog will always show as empty. An issue cannot be in both the Backlog and in a Sprint at the same time.

If you want to see all the issues of all Statuses in the QUELL project, and you want to see the Backlog (issues not in sprints) plus all currently active and planned sprints, then your filter should be simply

project=QUELL ORDER BY RANK ASC

If you want to be able to drag and drop the issue to re-order their Rank (order in which they should be worked on) then the ORDER BY clause must be just RANK. Adding anything else to the order by clause will prevent you from dragging and dropping issues to re-order them.

If I have missed something, please let me know why you are including in your filter criteria for issuetype, status, and Sprint.

[Peter Cornelius]

That solves the backlog view. Now I can see everything! 

Unfortunately it makes the scrum board completely useless. 

Each team works on their on board. Now one of those boards contains all work across the whole company. 

Do I need to have a throwaway board to just swallow all this and set up new boards underneath? 

[Trudy Claspill]

If you want to see the entire backlog, you need a board for that. If you don't want to see the entire backlog and all sprints across all teams in one place, then you don't need a board for that.

Note that there is no concept of "boards with boards underneath". There is no hierarchy to agile boards. Each board is its own resource.

If each team works on only a portion of that backlog, each team could have its own board also. Every issue would need to be flagged in a way that identifies to which team it belongs, and that flag would need to be included in the filter used to construct their board. For instance

project=QUELL and <field>="Team A"

There are a variety of ways you could flag the issues; using the Components field, the Labels field, or another custom field.

You would need to ensure that when issues are initially created, that flag for team ownership gets set. Otherwise you could end up with issues that are not on any team's board.

And, is there ever a chance that an issue could be owned by more than one team?

Also, each team should be naming their sprints in a unique way. Jira allows multiple sprints to have the same name; you can have multiple sprints all named "Sprint 1" but created in different boards. This can be very confusing to teams working in different boards and result in the teams using each others' sprints, which leads to confusion when trying to start and complete sprints. Each team should name the sprints uniquely, like "Sprint 1 - Team A", to avoid that confusion.

 Another alternative is that rather than having teams all work in one Jira project, each team gets its own project. Making that decision should factor in if the team is working on the same product, and how you will need to generate reports for the teams' work.

[Peter Cornelius]

Thanks for the help Trudy. 

What I expect from jira is to be able to see all sprints (active and future) and the backlog in one place. That's what happens when I click the left menu "Backlog" with no filter. 

I want teams to be able to fill their separate sprints from a single backlog. I expect those sprints to have separate boards without cross contamination. This is currently done by simply creating multiple sprints. It works very well for us. 

I think I just found the root of my confusion: 

"Project / Quell / boardname"

That's the path I see whenever I click backlog. It seems jira expects backlogs to be board specific. Is this because boards are expected to be host multiple sprints? 

Could I get what I want by: 

1) removing all team boards except one

2) Creating separate sprints within this board. 

Now There should be one backlog, many sprints and total visibility. Is that right? 

[Trudy Claspill]

First, some background.

Issues exist in a project, and an agile "board" is a method to manipulate those issue following an agile methodology (scrum or kanban). The agile board is the resource that holds the board view of cards and the configuration of that board, the backlog, and, in the case of scrum, the sprints. Board, backlog, and sprints are a bundle.

The content of the agile board/bundle is based on the filter on which the board is based. That filter can be found on Board Settings > General. How that information is distributed between the backlog, board, and (optionally) sprints depends on the configuration of the board. So, in a way, the backlog is board specific

Be clear that the issues are not "owned" by a board. An issue can appear on multiple boards because the content of the board is based on a filter and an issue can meet the criteria of multiple filters.

Sprints are created within scrum boards. Behind the scenes, Jira keeps track of the board in which a sprint was created. However, a given sprint will appear in ANY scrum board where either of the following conditions are met:

1. The sprint was created in that board, or

2. Issues have been added to the sprint that match the filter for the board.

If you want to see all sprints and the entire backlog in one place, then you need a Scrum board/bundle with a filter that will show you all the issues that comprise the backlog. If your backlog is comprised of all the issues in the QUELL project, then the filter you need is 

project=QUELL order by RANK desc

This board would show you all sprints that contain issues assigned to them that are part of the QUELL project. That includes active sprints and non-empty planned sprints.

If you want to see all Planned sprints that are empty (no issue added yet) those sprints will have to be created in that same board. If the sprints are created in another board, they will not show up in your board until an issue within the scope of your board has been added to the sprint.

I'm not sure what you mean by 
"I expect those sprints to have separate boards without cross contamination."

See my comment above about the conditions that determine in which board a given sprint will display.

If you use just one Scrum board, eliminating all the team boards, and create all your sprints in that one board, you will have total visibility.

[Peter Cornelius]

Thank you. 

I will try this when our sprint ends since jira doesn't allow for such things mid sprint without deleting all issues in certain boards.  Hopefully this does the trick.

[Trudy Claspill]

Be advised that if you delete other boards in which sprints were created, those sprints will also be deleted.