Creating nested teams in Visual Studio ALM

I just got a question on Teams without areas using Team Field in TFS and I decided that it warranted a bigger answer. The question was around creating nested teams and how to achieve it. Now, this applies to both Visual Studio Online and Team Foundation Server if you are using area path, and only TFS if you are using Team Field.

With TFS 2012 the product team introduced the concept of Team. Team is kina like a glorified security group, so it has members which are your team. However we often have some sort of hierarchical, or nested, team structure within our organisation. So let’s paint a hypothetical.

I have a company, Awesomecorp, that is currently working on two major products. They have Omniworks, which is a custom source control solution. And they have Multiplex, which is a document management solution. Each product has a vice president of development and they each have their own development teams working to deliver software.

clip_image001

They often have organisation level initiatives and goals that span the entire organisation and do kanban at the executive and portfolio level. Because they did some investigation and understood the issues around multiple team projects they ended up with one team project to rule them all called “Awesomecorp”. They still want to have some way to represent their nested team and product structure so that and want to have a way to segment each of their teams and reporting.

Lets take the out-of-the-box Area Path approach to the problem… I will augment with notes where the solution differs for Team Field.

clip_image002

If we were starting from scratch your first job is to create a new team project for Awesomecorp. They will be having only one team project as they are a small-ish company with only two products and five teams. If you had products with many tens of teams then you may want to use the isolation of a Team Project for each. In this case you should create a Team Project Collection for each product, each with a single Team Project. This will give you independent backup and restore, as well as the ability to sell a product and the collection goes with it.

clip_image003

Your new virgin team project is bereft of all configuration. Head to the Admin, the cog in the top right, to get started.

clip_image004

When you create a team project you always get a single team that is configured as the default. The default team is kina hidden from lists as you select only the team project to select it by default. While this confuses some users it is way less confusing for others who are not interested in teams.

clip_image005

Head on over to the Area tab and create your hierarchy for your nested teams. If you want to have a team at a level then you should create a node for that level. Here we have only three levels of teams as per our diagram. Things to note here is that for this team, remember that we are on the default team, there is two key configurations.

There is a column of check boxes at the start of the area path. If you check a box then you are saying that, for this team, this is the content that is shown in your teams scope. In this case the scope for the default team, which will become the Portfolio team, is everything.

The second key option here is the “sub-areas are included” option. If you experiment with it you will find that if you say “sub-areas are excluded” then only items that have the exact matching area path will be included. If you say, assigned a PBI to Team 1, it will not be shown if you exclude sub-areas. However, here, we want to include everything for our portfolio kanban boards to flow.

If you have your Team Project configured for Team Field you will not be able to “include sub-areas” as the list of teams is flat. You can however configure a Team to ‘own’ multiple values from the team dropdown allowing you to simulate hierarchy and maintain nested teams there.

clip_image006

We now need our teams. Here I am creating a Team for each level that I want to manage independently. Make sure that you uncheck the “create an area path with the same name as the team” as I have already created all the Area Paths that we need.

Once you have all of the teams created we need to look at mapping each of the teams to the respective bit of the hierarchy that they care about. This will give us our virtual nested teams so that we can get the views that we are looking for.

clip_image007

This, to be honest is the hard part to understand. The concept of relating this flat team list to the hierarchy that is the Area Path can be a little confusing.

It gets worse conceptually in that a single team can actually own two nodes! Let’s say that we had Team 5 doing work on both Omniworks and Multiplex. We could have two “Team 5” nodes, one under each of the parent node and the team could “own” them both. That team would see a combined backlog and boards that contained all of the items within that scope. And yes, while you have to have a single ‘default’ you can set “sub-areas are included” differently. It can get a little strange… simple is better.

If you have Team Field configured the Multiplex team must own “Multiplex”, “Team 4”, and “Team 5, values in order to simulate the “sub-areas are included” functionality you get with Area Path… this gets old quick if you have a complicated structure.

clip_image008

The goal now is to configure each of the teams with the area paths that they own. To do that you need to first select the team that you want to configure.

clip_image009

Once selected you will get thrown out to the Overview tab for the Team configuration and at the top of the screen you will see “[team project] > [team]” displayed to signify we are not looking at the teams configuration.

Head over to the “Area” or “Team Field” tabs to do the configuration.

clip_image010

On the Area tab you should check the box beside the level that you want that team to own. In this case we are owning the “Omniworks” level. Then go and do this for each of the teams in turn… and we are done… Area Path now controls out nested team structure and what our dashboards show.

clip_image011

Above I am selected on the root team which I have named “Awesomecorp Portfolio Team” and that will show the entire body of work for Awesomecorp. This will be the case for all of the boards as well, so you will see all the work underway in a sprint. At the Portfolio level we are probably only concerned with Features and generally how the PBI’s ar3e getting on to achieve them.

You can have additional levels above Feature, and I have seen Epic, or Goal, Or Imitative. Portfolios concern is above the backlog.

clip_image012

On the “Omniworks Product Owner” backlog you will see everything from the Omniworks product but none of the Multiplex product work. This lets the owner of the Omniworks backlog focus on prioritising only what they care about. They can view Features that are assigned to them, however in this case none of the features have been assigned to the product, however if I use the “View” option to “look-up” at features the tool will bring in the features that we care about.

clip_image013

If we select “Omniworks Team 1” we get only the work that has been assigned to that team. With custom boards as well as Sprint Planning and all the other trimmings of managing a team.

Conclusion

This format gives us a huge amount of flexibility to create and manage work within any agile process as well as supporting non-agile processes as well. If you know your way around the configuration there are many ways to organise and visualise the work that you are doing and still work predominantly within the bounds of the tools.

This is an fantastically flexible system and I encourage you to play around and figure out what the best configuration for you is.

  • Arthur

    What are the advantages of using “nested” Area paths (parent/child relationships) to achieve this as opposed to simply selecting multiple Area paths for a given team? I realize the list looks cleaner that way, but are there any functional differences? Put another way, would my backlog look and work the same way if I checked the boxes next to the Team 1 and Team 2 area paths if they were siblings of Multiplex as it would if they were children of Multiplex?

    • It would work differently. If you are using the hierarchy you can use the “include child” or “exclude child” to automagically bring in sub teams to a parent team backlog… or not… If you are using a flat list you would need to go configure a bunch of teams for each change.

  • Gary Tunnicliff

    Hi Martin
    Are the sprints different for each team? How hard is the reporting for each team and the roll up for say 2 levels? Tagging and querying still seem to have a prominent part to play

    • They are not. Same sprint for each team. They each get their own sprint backlog by area/team field so there is no seeping. I often roll up two levels, however you need to accept that you can roll up story points for teams that don’t plan together, or really burndowns.

      I use this in combination with other reporting, Reporting Services on premises and PowerBI on VSO.

  • Grant Abernethy

    Hi Martin,

    I’ve gone down the path of using nested teams where each of the product managers on my team have their own work area, then under each of those are the actual product areas that each PM owns. There are 4 higher level Directors that have several PMs reporting up under each of them. I was going to nest the team hierarchy under each director according to org structure.

    The reason I’m doing this would be to allow each of the director level PMs to see the health of their reports by product area as well as activity. I’m achieving this by pinning charts of work item types to each of the directors’ home pages.

    Lastly, the CTO will have his own team under which all other hierarchy exists, this then gives the CTO line of sight to the entire team’s health per release. We still operate on three releases a year due to customer need (we can’t yet develop and release parts of the code without causing disruption), but we are slowly moving toward being more Agile within those three development cycles. Therefore, I see value in allowing the CTO to see how the current release is progressing.

    I’m sharing all of this because I have some questions:

    1. Does the above explanation seem like the best way to accommodate our team structure?
    2. Will I be able to support requests for metrics at each stage (PM, Director level PM, and CTO) ongoing, or am I getting myself into a world of hurt?
    2. Our teams are pretty fluid, so PMs either gain new product areas, give up others, or swap between PMs. I think that this can be supported as long as the recipient of a new product area has that work area built as a child under their node/team first, before deleting it from the previous PM. Then I can use the mapping feature when I delete the work area from the previous PM. Am I thinking about this process correctly?

    Thanks for all the information contained in your blog posts!

    • 1) It does, however I would take it slowly as I have not setup that deep a hierarchy before and you may run into niggles. Remember to make the PM/Director/CTO an admin on his own team so that he can edit things.

      2) If that is your hierarchy in your area path then you will have very good control over reporting levels. Most of the reporting services reports are already sliced by area, and this would allow you to mix and match any level.

      3) This is where you are likely to run into trouble. TFS, like agile, assumes long running teams of at least a single Sprint. I think the capacity planning and other aspects will break down fairly quickly…

      • Grant Abernethy

        Thanks Martin. I agree that the planning tools may break down, but I’m pushing for some more concrete product alignments, and as it stands now, we (as PMs) are usually locked into a set of product areas for at least a year, so we’ll be getting better about less fluidity.

        Again, thanks for your responses.

  • Dusan Divljak

    Hi Martin,
    is there any posibilty to display hierarchy of teams in “Browse Server” window?

    Kind regards.

    DD

    • There is not. Since the hierarchy of the teams is virtual TFS really knows nothing about what you want. You can make it look like a hierarchy by naming the teams “ProductA-TeamA”… not pretty but will get the job done…

      • Dusan Divljak

        Tnx

      • Johnny Boldt

        It does not get the job done if the combined teams are more than 64 characters. We need team hierarchy, and this is a show stopper for us

        • That sounds like you have bigger problems than nested teams in TFS.

          • Johnny Boldt

            We are a IS team with over 100 people. We have enough groups that concatenating from the top to bottom groups exceeds 64 characters.

          • Johnny Boldt

            We are a IS team with over 100 people. We have enough groups that concatenating from the top to the bottom groups exceeds 64 characters.

          • Again, it sounds like you have bigger problems. Can you email me on info@nkdagility.com with more info?