Is it possible to have multiple backlogs for a single team in Azure Devops?

Question

Sorry if this isn't the right place for this, but all the devops question I see on stack exchange seem to be in stackoverflow.

I've begun working with Azure DevOps, and something I'm noticing is that managing items becomes more cumbersome as I add in more bugs, stories, etc... I'm searching for a way to be able to manage and prioritize these items more easily, and I was wondering if it's possible to have multiple backlogs. Say one for bugs, then one for enhancements, one for support tickets. The issue I'm running into is that we only have one team of developers, so ideally this would all be housed under one team so all these items can be dealt with in a single team's sprint instead of a sprint for each team.

Initially I thought that queries might be a viable option, but when creating them I quickly learned that I cannot reorder items. So that ended that idea.

I also considered just viewing the backlog with a filter to only show what I'm looking for, but that too does not allow me to reorder items easily. It looks like I can drag n drop them, but that doesn't work. I can open the ellipsis menu and choose "move to position", but that's far too clunky of a solution when you have many work items. I also sometimes get conflict errors when trying to move them in that manner.

So I keep coming back to the idea of multiple backlogs for a single team. Is this possible? I don't really see anything in the documentation, and I don't even know if this is considered best practice? Any insights are greatly appreciated.

Answer 1

One good way to do this is through the use of Epics. Epics are one step above Features. So, you could have an Epic for bugs, an Epic for User Stories, and an Epic for Support Tickets. What I don't know is if you can restrict team members to a single Epic. If you can't people just need to be adults. Within the Epics, you can re-order and organize your items.

You should be able to customize these objects and their hierarchy.

Answer 2

As danielorn's answer, you can set up multiple iterations. But you don't need to set up multiple teams, you can just use your currently team.

You can try the following steps to see whether this method can fit your requirement.

Step 1. Go to Project Settings -> Boards/Project configuration, create some new child Iterations of your project. In your case, you can leave out the start and end dates of the iteration. Just like this:

Step 2. Go to Boards/Backlogs -> View Options (top right corner) -> Choose "Planning".

Step 3. Click "New Sprint" in the Planning Side Pane, add the Iterations you have created in step1 to the Planning. (Of course, you can skip step 1 and directly create new iterations here, but the iterations you create here must have start and end dates.)

Step 4. Drag the work item to the corresponding Iteration. Then click the iteration, you will see a "new" Backlog that only has work items of this iteration.

Answer 3

Sounds like you have tried the out the most obvious ways of filtering and searching for workitems in the backlog and on the boards.

What you can setup is an hierarchy of area paths and (sub)teams to allow for filtered view of the backlog.

Consider the following structure of area paths

ProjectName
  - Bugs
  - Enhancements
  - Tickets

Then you create 4 teams, each corresponding to one node in the Area Path tree (make sure to tick the box include children for all of them). As you now have 4 teams you also get 4 backlogs. The top level team that maps to ProjectName will contain the full backlog (equivalent to what you have now). The other three will only show workitems under their respective area path. You can now use those 3 teams to view filtered versions of the backlog (or boards), but still maintain a single backlog on top level.

As Iterations are defined per project, and are shared across teams, you can continue with one set of iterations and add them to all teams, making them shared.

By this setup any team member can jump between the different subteams to view their preferred filtered version of the backlog (or the complete backlog on the root team)

This feels kinda hackish, setting up new "Teams" just to filter the backlog and whether this is considered best practice or not isn't straightforward to answer. Generally an Agile team should have one backlog and prioritize it as a whole but one could argue that the top level combined backlog fills that purpose and the sub backlogs are used for easier management and for visualizing only parts of the backlog. After all Agile is not about tools it is about being productive.