Buying into the Team concept of TFS 2012
The irony of Team Foundation Server not having any notion of teams per-say in previous releases has not been lost on us. Some of our 2010 customers know that we actually had to come up with our own implementation of such a concept to support the practice of using one Team Project to manage multiple teams. I say some because our implementation has never been quite obvious with regards to its configuration which relied upon creating and maintaining an xml file on the server.
Microsoft, with the release of Team Foundation Server 2012, decided to make teams a first-class citizen of their ALM platform. Teams are actually a subset of a Team Project, each specifying Team Members, Team Iterations and Team Areas. This new functionality overlapped our previous implementation and we've postponed adding support for either solution until we decided which one would benefit our customers the best. We've always worked to ensure that Urban Turtle feels like a natural extension of Team Web Access, integrating some of its features into our own experience. This played a major role in our decision to implement support for the concept of Teams in TFS 2012 rather than rolling out our own, like we did in our previous release.
Back to Basics
The notion of Teams in Team Foundation Server 2012 may be unfamiliar to some of you as it is a newly introduced feature with this release. For starters, the default home page in Team Web Access does not make it obvious that you can actually split Team Projects into teams. You could actually conceive, develop, build and ship a product without ever knowing about teams.
The first thing to know is that there is always a selected, or active, team in Team Web Access. It is displayed at the top of the screen, as such:
Now, you're probably thinking that what is shown here is the project, not a team, and you would right. Actually, we would both be right as a team project always define a default team. Clicking the project or team name brings up the team selection menu where you can select the Browse All option. This displays the Browse Server dialog which showing that Tailspin Toys is actually the project's default team and not merely a team project.
For the purpose of this blog, we'll pretend that the Tailspin Toys project is developed by two different teams, Team A and Team B. We will start by creating these teams under the Tailspin Toys project. To create teams, we first need to access the Administration area by clicking on the gear icon located at the upper right corner of the screen.
This brings up the Administration section with an overview of the currently selected team project. This is where we can add new teams by clicking the aptly named New team button.
While we can specify a description, configure default permissions and assign administrators from the Create New Team dialog, we only need to specify a Team Name to get started.
Once the team is created, we can set it as the active team from the team project dropdown menu at the top of the screen. Since this only lists recently accessed teams, the newly created ones will not be readily available. We will first need to click the Browse All option, pick the team, and click the Navigate button. This will set the team as the active team, making it visible at the top of the screen. We will now be able to quickly switch to this team from the dropdown menu instead of having to go through the Browse Server dialog.
We can add team members to a team from the Overview tab of the Administration area (remember, the gear icon). Looking at the breadcrumb displayed at the top, we can see which team is currently being administered. By default, this is the active team. We can simply click the Add... button to start adding members which are most often Active Directory users.
Team members are used in Urban Turtle on the Sprint Backlog and the Fast Track boards. A dropdown menu lists the team members and allows you to highlight work items that are assigned to the selected member. Items moved to the In Progress are also automatically assigned to the currently selected team member, a useful feature during daily stand-up meetings.
Managing iterations available to a team can also be done from the Administration area, by clicking on the iterations tab. This lists all iterations for the current team project, and not just for the team itself. Checkboxes are used to specify which iterations belong to the currently selected team. Only checked iterations and all the iterations underneath them will be visible throughout Urban Turtle. It is also possible to specify a Backlog iteration for the team, also known as the root iteration in Urban Turtle. Iterations that are not located under the team's backlog iteration will not be available in Urban Turtle. The backlog iteration is always selected and will appear as the top-level iteration in Urban Turtle.
We provide a shortcut in Urban Turtle to avoid the round-trip to the Administration area. On the product backlog, you can simply click the select team iterations link to display the Team Iterations dialog.
We recommend using a structure similar to the following for the best experience in Urban Turtle.
Managing team areas can also be done from the Administration section, by clicking on the areas tab. Just like for managing team iterations, Urban Turtle provides a shortcut to your team's iterations from the product backlog, by clicking the select team areas link.
Contrary to team iterations, it is not possible to configure a root area for your team. While there is a concept of default area in TFS, this is not used in Urban Turtle.
Leveraging the team concept in TFS 2012 allows you to have distinct backlogs for each team while retaining the ability to overview the progress of the project as a whole. Nothing compares to the way Urban Turtle allows you to juggle between multiple team backlogs while preserving the overarching context that higher level executives often require. Give it a try right now and don't hesitate to contact us should you have any questions or feedback.