Allow Teams to work over multiple Projects (Teams at the Collection level in Visual Studio Online)
This suggestion is migrated to Developer Community. Please use below link to view the current status.
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
John D. Shkolnik commented
Definitely needed. I've just hit this wall.
Nick Foster commented
This would be amazing. I run a team of 4 developers and we look after a platform of nearly 30 applications.
When I set up VSTS I made the error of creating a project per application. As we've added more applications/projects to the account it's made managing backlogs, iterations, deployments practically impossible.
I'm no looking at how to merge those projects into a single project using areas to separate the work out, but account-wide team/backlog/reporting/dashboarding would save us much pain.
The strategy that has been pointed out here: https://colinsalmcorner.com/post/vsts-one-team-project-and-inverse-conway-maneuver looks promising, although not flawless it could give the VSTS team at Microsoft a good insight in what's needed in a DevOps environment.
Tomas Deceuninck commented
Bartosz Borkowski commented
This is important for us too. We've realized we cant effectively plan work because we're way to small to have a team for every project. At times team(s) have to work on more than one project at the same time. There's no clean way to implement/plan this in current version of VSTS.
Pradeep Yellamaraju commented
This is an important feature for our team as well. Please provide some update and guidance on this.
Adam van Vliet commented
Please provide an update, this has been ignored for far too long.
Alistair Rose commented
Really could do with this.
I have a team bringing together applications from a company merger.
We currently have multiple team projects. We need to be able to link them to PBIs within the various projects. Most importantly, we need to allow a single development team to cover multiple applications that we currently have in separate projects.
I know that this can be done by moving to a single team project structure but the price to pay would be a TFS environment with way to many Git repository, builds, and releases to navigate. TFS needs more grouping. I know that it has made recent improvements in the build and release area but more grouping would be needed. Keeping separate projects makes more sense from a source code point of view but the people looking after them are the same.
Peter Molloy commented
The VSTS "project" concept and "agile" concept are actually what really causes the whole issue with "multi-product" "Agile Devops" support in VSTS. I don't believe there is much that Microsoft can do to with the current philosophical approach underlying VSTS. It would need a basic change to it's current workflow to enable true "Agile Devops". We have looked everywhere for a Devops environment that supports Product, Epic, Story, Solution, Project, Sprint, Task, Team and Team Member many to many relationships and workflow management. This would be a very powerful environment to continuously develop and maintain products, features and libraries. Hope someone comes up with it soon as we struggle to find the most efficient and effective processes to produce high quality software.
..I still struggle with this... the multiple teams within a Project does satisfy some concerns (like a unified board), however introduces other problems, (like mentioned in the OP and other comments).
Does this extension help satisify the "cross project kanban" concern:
I get various results.. sometimes it works fine,other times it struggles... but is this the stop gap we were looking for?
David Richards commented
This is a big problem for us - teams that work on quite a few small projects (with a need for some customers to access VSTS, which largely makes single project approach a non-starter).
As an interim, wouldn't it be possible to just let an iteration pull in items from across projects? That way we could arbitrarily define the team in whichever project, then pull in all the work we need to for a sprint, using that project's board to track progress.
Denis Ouspenski commented
In definite need of that, working on three different projects and have to switch all the time.
Christopher Mank commented
Setting up a new TFS instance for a company and would love to see where this is at. It really seems like the "many team projects" is how the product is meant to be used, especially from an administration and security perspective. However due to this limitation, it seems the best option today is still the "one team project" due to how you can view boards. I would love to see an update on this because locking down teams/code/etc. using the one team project approach is much more work and overhead when at the project level, it's all setup for you.
Chris Bernsdorf commented
I whole heartedly agree that the biggest shortcoming my team has with VSTS is the ability to plan/manage the backlog across multiple projects. I manage a small team that works on several projects over the course of a sprint. As requests come in there is no way to track them across several projects and manage the overall workload of the team.
Joe Termine commented
One of the issues leading us to consider using something other than VsTs or Visual Studio online is that project teams cannot be shared across multiple projects. There are a number of workarounds, but this particular issue is a troublesome oversight.
Wouter Stevens commented
Teams shouldn't be assigned to only one or a list of projects nor features. Teams are working in the real world cross features and cross products. Doesn't matter working in Kanban, Scrum nor Agile methods, they pull work in, and it can be from different features / products.
Teams should be cross team projects but also cross features so please don't enforce to use to assign areas to teams!
This is a huge drawback of using VSTS and using digital scrum boards.
We have the exact same problem, need a Kanban for multiple projects.
I'm my company we have not used the One Project approach, and this is very annoying...
We need to build our own solution to be able to view all the projects status.
I really don't understand why Microsoft keep on developing tools like if only one project existed in a collection.
For example the new release feature is great, but again, its all per project! Task group, are... per project and not reusable from one project to another... why?
Please fix this, we are working on multiple projects!
Nathan Lake commented
Out company (80 devs) are all working within one project entirely due to our inability to view a Kanban board across multiple projects. This forces us into lots of odd workflows and configurations. We really need a cross-project Kanban board.
Jasper Siegmund commented
Interesting topic as we're facing similar problems as well. In the comment of Brian Harry (Jan 18 2017) it's mentioned that some features would be coming in preview soon. So did I miss something? Are these already there? We have a similar set-up as others have. A single (6-person) dev team that supports multiple applications. I want to have each application as a project in VS but all of the work stuff should be combined. The best option I could think of is to create one project that doesn't have any code but is just there for work item tracking and creating the application projects separately for repo, build, release, all that kind of stuff. But the way things inside of a project are linked created some additional work when following this approach.