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

Question

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.

Nic Brough -Adaptavist- · Answer

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?

Lars Torngren_ah6q75 · Answer

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

Jens Pilemand Ottesen · Answer

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.