Visual Studio Team Services/TFS 2015 Project Structure

4
votes

I have been reading a lot on the recommended project structure in TFS. I am considering moving my company to Visual Studio Team Services (was VS Online) and have been trying to set up and test to get my head around how it will work. Based on articles I have been reading, it is recommended to have one team project with many areas/iterations/teams (http://nkdagility.com/one-team-project/, http://nkdagility.com/working-within-a-single-team-project-with-team-foundation-server-2012/).

What I am struggling with is how to make this work for my specific environment and what I would like to see. We are a small development team consisting of myself as a manager and 2 developers. With our current structure (outlined below), I cannot see across team projects for our full backlog. To see how individual work is progressing, I would have to go into the individual team projects.

Current Structure

  • TFS (Server)

    • Accounting (Collection)

      • Application 1 (Team Project)
        • Release
        • Test
      • Application 2

    • Engineering

      • Application 3
      • Application 4

I like the idea of being able to see a master backlog and then assign work items to the individual projects. However, I would still want to be able to manage sprints and see burndown charts down to the individual project level. For example, if developer 1 is working on Project 2, I would like to assign PBI's to that project and see the burndown chart at that level.

New Structure

  • Team Services (Service)
    • DefaultCollection (Collection)
      • DefaultProject (Team Project)
        • Accounting (Area)
          • Application 1 (Application)
          • Application 2
        • Engineering
          • Application 3
          • Application 4

Basically, as a manager, I am looking to be able to see a status of where we as a department stand in our overall backlog. As a developer, I want to know what items are assigned to me, regardless of which application they are related to. Am I on the right track for this? In typing this question, I've almost convinced myself that I don't actually need to know backlog of an individual application. Rather, I should be managing all of the work across all applications and using that as a sprint backlog. Sometimes this sprint will be multiple releases in larger application and sometimes this sprint will be updates across multiple smaller applications. Any help that can be provided to help point me in the right direction will be appreciated.

2
tfsazure-devops

2 Answers

1
votes

The new structure is good. And you can create two teams from your project Control Panel\Overview: one for Accounting and one for Engineering. Check "Create an area path with the name of the team" option when you create the team. Then you will have 1 overall project page for your team project and 2 sub project page for Accounting and Engineering like following:enter image description here

In the overall project page, you can manage your overall backlogs, check the Burndown charts for the whole project. And in the sub project page, you can manage the backlogs and check the Burndown chart for individual project.

2
votes

You can create multiple teams in the same Team Project and you can nest them to facilitate hierarchy.

http://nkdagility.com/creating-nested-teams-visual-studio-alm/

You can see how to configure this in my post above. It's fairly easy to use...