Is it possible to have multiple backlogs in a single Board?

[sham.ahmed]

User has a project with a Board that has started to expand out with issues, some issues are for different segments of the project however they don't want separate boards for this, they would like one single board with multiple backlogs for each of the segments, or if having multiple boards is required, they would like a centralised layout where they can see all the backlogs for each segment together.

[Lars Torngren]

I would suggest (as you mentioned) to use labels for each project (and possible product) so that you can utilize quick-filters to see the relevant tasks for your specific product. Then you could use one backlog for all of your tasks

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

This would make no sense.  I can't think of a reason why you would want to have different backlogs - the backlog is a feed for the board effectively, and the feed needs to be controlled by the whole team, you wouldn't want a board having multiple feeds, it makes it impossible to plan.

The board and the backlog are just different views of the same thing - your list of stuff that needs attention from the team.  The backlog lists everything, a Scrum board shows the active sprint, and a Kanban board all the work currently selected for action.

[Jens Pilemand Ottesen]

My team owns 3 different product. We mostly work on 1 at the time for some months, then on another product. But tasks for non-active products always pop up, and we want to include them in our sprints to work on them. And non-product-tasks too.

What would be the best approach?

1) 4 different projects, 3 products and 1 board for the team. We only create sprints on the team projects, and take tasks from all 3 product-backlogs.

2) One board for the team with Fake Product-backlog-sprints for each product?

3) (above suggestion, i think) One Board, with a mixed backlog of 3 products and other tasks. Using Labels (?) to filter product-backlogs.

[Nic Brough -Adaptavist-]

You say "4 different projects, 3 products and 1 board for the team." which suggests that you conflate projects with boards.

A project is an issue container that defines how the issues within it work.  Most projects are aligned with a product, a related set of products, a team, or a specific task (e.g support, or booking things).  But they could be aligned with anything else you want.  The critical bit is that similar issues within them work the same way, and they control who can get in and do things in the project.

A board (and its backlog) is a view of a selection of issues that a team is tasked with dealing with.

A board can select from anywhere.  I often recommend boards that select things like "Project in (A, B) or label = C" for teams with a couple of projects on the go, and sometimes have people ask them for help with issues in other projects.

So, I would say your option 3 is by far the best, but only on the board part of it.  You have one team, so have one board for that team.  

How you distinguish between products is a different story.  I would look to your users as well for this one.  When they create a story for your team, would they get a label right?  Or a component?  Or a select-list field?  Do they know your products well enough to mostly get them right?  If you reckon they would, I would probably go for a single project, to try to keep it simple.  If you're not sure, then three product projects might be better.  Or your team might say "we're happy to correct them when they choose the wrong thing".  I can't tell you what process might work best for you, but "one project, with product identifier" is just as good a way to do it as "three projects, one per product".  Talk to your developers and users - what would they prefer?