4

I would like to know what is the concept of Team Project in TFS 2010. In my company, there is a single team working on multiple products at the same time. There is a visual studio solution for each product. We are following SCRUM methodology. Our product back log and sprint back log basically comprises of items related to multiple products, so during the sprint the team works on backlog items relating to multiple products. We are looking forward to use SCRUM Process template for TFS 2010.

I was wondering what approach should i take in terms of organising the projects in TFS Source Control and making full use of the TFS Process Template(SCRUM)?

  • Should I create a Team project for each product? But that would mean I will have to maintain process template, product backlog and sprint backlog for each Team project. Especially when creating and querying work items, it will involve lot of switching between team projects in team explorer. Similarly, when creating burn down charts/reports, there is going to be one for each of the Team project. This seems like a nightmare!

  • Or should I create one Team project and put all the products(Visual Studio solutions) under it? This sounds better to me because, there will be one process template, one product and sprint backlog and one place to look at/query all work items.

To me it seems like Team project should map to a Team and not to a Product or Visual Studio Solution. However in my past experience, I have come across places where Team Project is mapped to product/visual studio solution and I am a bit confused.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
nabeelfarid
  • 4,156
  • 5
  • 42
  • 60

2 Answers2

4

The term "Team Project" is confusing. I really wish Microsoft had used a different phrase.

Having said that, I don't know what other word or phrase would apply.

  1. A Team Project does not necessarily correspond to a Visual Studio project or solution
  2. A Team Project certainly doesn't correspond to what SourceSafe used to call projects (those were just folders)
  3. A Team Project doesn't necessarily correspond to a single source control tree. The people working on a Team Project may use code from multiple source control trees (assuming this can be mapped into your workspace correctly).
  4. A Team Project more closely corresponds to an endeavor of some kind. This may or may not involve some source code. It will involve some people. It may or may not involve some work items, or builds, or reports, or portal sites, or lab environments, or any combination of those artifacts that are scoped on a per-team-project basis. These will usually be artifacts that will be useful to some "Team" in accomplishing their "endeavor" (which may just happen to ba a matter of producing and releasing some code, using the help of work items, reports, source control, builds, etc.)
John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • 2
    I tend to use the rule of thumb that if they ship together they are a team project. That doesn't mean teams aren't successful in using Areas, iterations and source control folders to partition endeavors that have unique timelines. – Ryan Cromwell Jul 29 '11 at 03:00
  • 2
    Interesting. I might modify that to say, "if they are _meant_ to ship together". This would rule out cases where they _happen_ to ship together, or where it is later decided to ship them at the same time. – John Saunders Jul 29 '11 at 03:11
  • Yes, that more clearly states my intention. Budget and owner often come into play as well, but those generally surface as timeline differences as well. – Ryan Cromwell Jul 29 '11 at 03:46
  • @Ryan: and those are often part of the definition of the "endeavor": "The stuff that the Accounting and Audit Departments mean to release on August 1". – John Saunders Jul 29 '11 at 14:13
  • This seems like the most Generic answer ever :) My main concern though is, if I am going to have several team projects for one team, then managing process template for each of them, especially reports like backlog, sprint backlog, query work items and burn down charts etc means there is going to be one for each project which doesn't make sense, As the team would like to view these things together as if they are part of one sprint. – nabeelfarid Jul 31 '11 at 22:00
0

I would advise you to create one team project and multiple folders for different solutions. In other words leave your work as it is and create just one team project.When checking in products codes use server folders. This way you have a unique repository with shared work items and reports

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Raouf ben hassine
  • 1