Create a new backlog on a board that has multiple existing backlogs

[ryanjohnsond]

What are the steps to create a new backlog on a board that has multiple existing backlogs on it?

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Backlogs don't belong to projects, they're part of a board.  For certain types of project, the answer is "yes" though  - you can create multiple boards that draw in issues from your proect and that board will have its own backlog, separate from the others you may have created.

[ryanjohnsond]

Hi Nic, Sorry. I wrote the question incorrectly...

Re-stated Question: "What are the steps to create a new backlog on a board that has multiple existing backlogs already on it, but I want to keep the other existing backlogs too?"

Background: I just wanted to create another backlog called "UX Backlog," that when I do, I will see it at the bottom of the other teams' backlogs on the original board.

I am on a large multi-team software program that has on its board, multiple backlogs for each team's sprint. I am an admin, and I can create a board. But when I did, it placed all the existing backlogs in it. But that's not what I wanted. I just wanted to create another backlog called "UX Backlog," that when I do, I will see it at the bottom of the other teams' backlogs on the original board. 

[Nic Brough -Adaptavist-]

Um, you can't actually do that.  There's no such thing as "a board with multiple backlogs".  A board has a backlog, that's it.  The board and backlog are two ways of looking at one thing.

So, I'm now very confused on what you are doing, as there's no way to have multiple backlogs in a single backlog.  Do you mean you have multiple boards defined differently, and therefore having different backlogs that might include the same issues?

[ryanjohnsond]

I need to get the terms clarified first. I know the classic definition of a backlog is a "dedicated space for defining epics, stories, tasks and bugs for a project (development effort)." How do you use the term?  What's a Jira "board?" What's a Jira "backlog?" What are multiple containers called in Jira that function as multiple backlogs when a user selects the "Backlog" option in the left margin? Those multiple containers within the backlog menu option all seem to me to be functioning as micro backlogs.

At work, the admins set up a Project that contains multiple boards, and a backlog for each that holds multiple backlogs or containers with unique names that hold epics, stories, bugs, etc. 

Here is how I interpret Jira's software: At the top navbar for Jira, I see the hierarchy of Project. I select a project and it loads it. At the top left margin, there is a dropdown that can hold multiple boards. Select a board, and the page loads. Select the backlog of that board; it loads the page. As I scroll down the page, I see multiple backlogs: one is called backlog, another Sprint 113, another Team RedRiders. There's about 10 of them. These are each holding epics, stories, bugs, etc. Question: What do you call those in Jira?  We are calling them backlogs. 

[Nic Brough -Adaptavist-]

I think this is what is confusing you:

I see multiple backlogs: [...] Question: What do you call those in Jira?  We are calling them backlogs. 

These are sprints, not backlogs.  You'll need to stop calling them backlogs as it is totally muddling you up.

You're looking at one backlog, which is a list of stuff that needs some attention for some reason.  You've put that list in some order and at the top of it, defined one or more sprints.

A sprint is a time-box for getting stuff done.  You put items into a sprint, start it, and the contents then become the cards you see on the board - the board is a view of the active sprint.

[ryanjohnsond]

Thanks, Nic! Makes total sense now. I'll create a Sprint called "UX Backlog." 

Follow-up Question. How do I DELETE the "board" (with all the sprints) I made earlier? 

[Nic Brough -Adaptavist-]

I wouldn't do that - you're still confusing what the sprints and backlogs are by calling a sprint a backlog.  A sprint is not a backlog, it's a slice of a backlog, and it's going to change.  

Look at it this way - at the end of the sprint, everything in it should be done.  You won't be using it again for managing work.  i'd recommend calling it "UX Sprint 1", and then when you've finished it, you can take another slice of the backlog and call it "UX Sprint 2"

You can delete boards from board config or the list of boards (under "my work")

[ryanjohnsond]

I am a little new to Jira. We are a multi-team project. UX needs a staging backlog that keeps tons of research work. We have a conceptual model of how we wan t to work. I think Jira won't let us do this, so the PO and other members have named sprints, "backlogs," by using sprints as backlogs and stacking them on top of each other in the same page. Why? The PO has a sprint called "backlog." It's a perpetual sprint that is used only as a holding bin until she assigns the stories to a team's sprints. Another example: UX needs a backlog of work that are not assigned to a teams, and have not been refined and estimated. When ready, we want to be able to assign/drag those stories into the developer's backlog where we can estimate them; and then from there, they will then put stories into a new sprint.  Another team has a Sprint called "Staging," but it's really acting as a backlog. I suppose we would call them those staging areas perpetual sprints that act as backlogs because we can't actually reproduce our conceptual model with Jira. 

Is there a way to help us match our conceptual model with Jira? 

[Nic Brough -Adaptavist-]

That really isn't going to work for you.  Sprints are simply not backlogs.

A better way to work would be to go with the way Jira does Scrum (or Kanban). 

It doesn't really matter if the issues are all in one project or spread across projects, as boards can draw from many projects.  You need a rule for identifying when an issue belongs to a team - the easy one is "project", but you could use a custom field, a group picker, select list, label, or even more complex rules (issuetype = defect or label = reported-defect)

Once you have a rule, you do the simple thing of Board = Team.  One (main) board for each team, with their own backlog (and proper sprints if you want to work like that).

[ryanjohnsond]

I just looked, everyone is using boards as backlogs. One has two sprints: the bottom is called "backlog" and the one on top is called "To do." If the software doesn't match the user's conceptual model, they will make the software adopt. :(

We need to arrange Jira like this.

Do you have any videos on how to do those hints you gave, e.g., 

"you could use a custom field, a group picker, select list, label, or even more complex rules (issuetype = defect or label = reported-defect). Once you have a rule, you do the simple thing of Board = Team.  One (main) board for each team, with their own backlog (and proper sprints if you want to work like that).

[Nic Brough -Adaptavist-]

The point of a backlog is it lists everything.  A sprint is a time-box you say "we're going to get these items done in". 

In Jira, the backlog shows sprints because it's easy to plan in one place.  Yes, you could call a sprint "to do", but when you complete it, what do you call the next one?

If you're not going to use sprints, that's fine, but I'd recommend moving to Kanban boards instead, to avoid all the confusion you're causing here.  They can have backlogs, but don't have sprints, you just say "we're going to do this" by putting it on the board.

That's why your sprints are not going to work for you - you have to start a sprint to get it on to the board, and a sprint should end soon, leaving your board empty.  It's not workable to leave it open, and it makes a nonsense of all your reporting.

[ryanjohnsond]

Just to make sure I understand how Jira works. If I create a sprint, it will go in the backlog but not replace the current sprint?

[Nic Brough -Adaptavist-]

You can move to Kanban any time - create a new board for the team, select Kanban, ask them to use that as their main board.

A sprint is a slice off the top of the ranked list of stuff your team wants to get done.  In the most simple case, a team will prioritise (actually, rank) their list so that the things that need doing next all sit at the top of it, and then they choose the top X issues to bring into the next sprint.

Jira's backlog even has a drag and drop line for that - you drag it down from the top of the backlog until the new sprint contains the issues that the team wants to commit to in the sprint.

In real life, that's just the starting point.  There are complexities like "we can't fit items 1, 2, 3, 4 and 5 in, but 6 is smaller than 4, so we could do 1, 2, 3, 5 and 6", uncovering dependencies after you've done the initial drag, or, stuff like "oh, if we can get this done, it makes sense to put item 4 into the following sprint".

On that last one, that's why the backlog lets us create multiple sprints - so we can drop more stuff into future sprints.