Background

Both VSTS (Team Services) and TFS (Team Foundation Server) have a set organizational hierarchy. An individual developer belongs to a team. A project (also called Team Project, or TP) has multiple teams, and a VSTS account – as well as a TFS collection – contain multiple projects.

While it is possible to run queries in Team Services and TFS that return data from multiple projects, and in TFS, reports that bring data from multiple data sources (i.e. multiple collections), the agile governance tools that VSTS and TFS offer do not aggregate beyond the project level. This means that the hierarchy that VSTS offers has 3 levels: Project, Team, and Developer.

In this post, I will show you how to set up VSTS so that you can create a larger reporting hierarchy, with as many levels as you want.

Teams, Teams, and more Teams!

First, a disclaimer – the following technique, while giving us almost everything that we could need out of multiple hierarchies, cannot create new types of containers or entities. The highest level is still the project, and individual members still belong to teams.

What we can do is set up teams within teams – or at least create the illusion of having done so.

A team in VSTS has the following attributes – it has members (the individual developers), it has its own set of dashboards, its backlogs and boards, and it is assigned an Area under the project.

The way that we specify that a work item is assigned to a certain team, is by specifying that the item’s Area Path is in or under an area assigned to said team.

The trick that we will use to accomplish our goal, is to create teams whose areas are under the area of another team. Each “level” will be a different hierarchical level. We will usually assign the products highest governance (or steering) team to the project root.

For example, if we want our project to have the following hierarchy:

• Division
• Group
• Team

We will create “Division” teams under the project root, “Group” teams under the divisions, and “Team” teams under the groups, as in the following hierarchy:

Again, the teams themselves are “flat” there is no team hierarchy. The illusion is created by assigning some teams a default area that is a “parent node” for another team’s area.

In this example, Alpha Group’s area is  MyEnterpriseProduct\Blue Division\Alpha Group, and the Apollo team is MyEnterpriseProduct\Blue Division\Alpha Group\Alpha Team, which is beneath it, but neither team has any other attribute that marks one as higher than another, hence the “illusion”.

But Will it Blend?

So we have successfully created a list of teams, some assigned to areas above others. How do we make sure that the illusion is kept when dealing with boards, backlogs and dashboards?

The trick is to set all but the “leaf” teams (the teams lowest in the hierarchy) to include sub areas, i.e. each team owns its own area and those beneath:

Setting the teams like this gives groups a supervisory view of teams, divisions of groups, and the “steering committee” can oversee all of the work being done in the project.

This means that the steering committee’s boards, backlogs, and dashboards will track all of the work being done in the project, while Alpha Group will oversee only the work done by its teams. Each of the “leaf” teams will see the work that has been assigned to them:

The Steering Committee’s backlog

Alpha Group’s backlog

Ares Team’s backlog

This filtering is preserved for the Kanban and Scrum boards as well, and each division, group, and team can have their own set of dashboards to highlight whatever they want to see and use to drive their decision making!

Summary

By creating an Area tree that matches the organizational hierarchy, and assigning teams to their proper nodes, VSTS teams can be made to create a hierarchy as high as the group needs it to be!

I hope you find this useful. If there are any questions, please feel free to ping me in the comments!

- Assaf