SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am just to start a new big sp 2013 project, I am studying different ways to organize the vs structure and one of the ways I liked is to separate for example webparts in different solutions:

Also, some libraries will be common to all projects.

The thing that is turning me crazy is that we will use team foundation server, and in tfs each project has its own work items and its work source control repository.

Lets say that I make a HR application, then I create the HR tfs project with backlog items, tasks, bugs, etc.

But, what about common projects outside HR, lets say that HR uses 3 webpart projects, and one common library to all projects. How would you organize these "external" or "common" projects?

Should I create a tfs project also for every single one of them? or one for all but without workitems, etc?

share|improve this question
up vote 1 down vote accepted

For groups that do a lot of small projects, sometimes it's best to have a TFS project for the Team, and not multiple projects per development project. For example, perhaps you're using scrum, and your backlog has items from HR and other groups. But, even though there are different "projects" with different deadlines and even different technologies, it's treated as one backlog. So, there's one daily scrum meeting where all of the smaller projects are discussed. And, there's one sprint, where folks spend time working on pieces of different projects. And, of course, this means that there is one TFS project to manage work items and such.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.