Allow Teams to work over multiple Projects (Teams at the Collection level in Visual Studio Online)
Migrated from Azure DevOps UserVoice forum
I would like to see enhanced support for Teams that work across multiple Projects or Backlogs. My initial thought is to pull the Team concept up one level so that Visual Studio Teams are created at the Collection level rather than the Project.
== Background Context ==
One of my favourite features in Visual Studio is the concept of Teams. However, we want our real world development teams to be long lived entities rather than dismembering working teams after a project and treating people as fungible resources that we pull together from the bench players. Although I love the team feature, we find the implementation is still very focussed on a single project. To allow our Teams to operate over multiple solution backlogs we have adopted "One TFS Project". We use Visual Studio Online as follows:
Project - Just the one (DefaultProject) home to many teams using this project for many unrelated product backlogs.
Areas - To represent solution backlogs (\DefailtCollection\DefaultProject\ProductA).
Teams - To represent real development teams (TeamA) but also virtual teams for product backlogs (ProductA, ProductB) where we tick a single area (\DefailtCollection\DefaultProject\ProductA). This alllows our stakeholders to groom specific Product Backlogs and we splice these together into one single Product Backlog for the development team (TeamA).
Iterations - To schedule work to a team's backlog we move workitems to the team's iteration which is at the root of the one project (\DefaultCollection\DefaultProject\TeamA)
This all works really well, it lets the Team visualise all their work in one backlog and inflight work on the one task board, but I feel we are (mis)using Visual Studio in an unintended (albeit very beneficial) way. A quick search for "TFS One Project" on the internet demonstrates we are not alone.
== The Problems ==
We end up with a lot of Builds & Repositories in the DefaultProject. So the negatives are mainly around organising, scaling out, and performance of Visual Studio to deal with many hundreds of things in one flat folder. The UI in Visual Studio IDE has a number of limits which create awkwardness: VS2013 only shows 100 Git repositories (have to resort to commandline) No folders for organising Git Repositories No folders for organising builds We use naming convention ProductPrefix-Component for builds and repositories