Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
We are setting up TFS 2010 and we have about 15 different applications we would like to migrate to TFS. We have already decided that we will do 1 collection. The question I have is should we create multiple team projects for each of our applications or should we put all of our applications under one team project? What are the advantages/disadvantages we would face with those scenarios for work items, builds, etc?
My bar for what should be in a team project is whether the applications and/or people working on the applciations have shared resources, like the work items.
In the upcoming TFS11 there is the notion of backlogs (if you haven’t seen it yet, I recommend to go to the \BUILD\ recordings). If your applications share the sprints or backlogs, then I would create one team project (or a team project per pool of applications that share these).
If the applications are developed seperately and you want to use different processes, then use multiple team projects.