ALM Rangers switching to single TPC/TP and multiple Teams model

We shipped the Team Foundation Server Planning Guide BETA a while ago and are currently in a holding pattern waiting for feedback from our product owner for the release candidate which is dusted, packaged and waiting for a go-for-launch sign.

In parallel the infrastructure working group is looking at continuous process and infrastructure improvement. One of the tasks is to prepare the team environment for the next wave of projects, which introduces new concepts such as discoverable queues for small ad-hoc tasks, centralised backlog and bug management and aligning our own infrastructure with our latest guidance.

So, let’s take a quick detour into some of the new concepts:

Discoverable queues for ad-hoc tasks

The typical ALM Ranger project has a small, geographically dispersed team and a bucket of challenges, which Brian covered in ALM Guidance: Visual Studio ALM Rangers — Reflections on Virtual Teams. The usual duration of the project ranges from 3-6 months, which requires an active part-time team over a fairly long period of time.

This already challenging ecosystem is a blocker for a few ALM Rangers, who can only deliver short-spurts of commitment at random times.

What the infrastructure working group is investigating is the introduction of an ad-hoc, self-contained task queue, from which these ALM Rangers can pick a task when and as they can. For project teams it is a place to drop (but not forget) self-contained tasks, which can be worked on in parallel to their project. A win-win situation Smile

Centralised backlog

Our current model is a single Team Project Collection and as shown 32 separate Team projects. The advantages are project and team isolation, however, the overall “wave of projects” monitoring and management using the tools out of the box, has proven a challenge. As shown below, the visual feedback is exception for individual projects, but to create reporting and especially overall burn down diagrams is not straight-forward.

Our wish list states one backlog for the ALM Rangers, which can be sliced, diced and viewed as one or from a specific project view.


Centralised bug management

The same challenges and wishes we have for the backlog applies to bugs. Using WIT queries that traverse all projects is feasible and used in our environment, but ensuring that the right bug is raised against the right team project, is adding unnecessary churn.


Aligning Rangers infrastructure with latest guidance

Stepping through the Team Foundation Server planning guide, as shown in one of the cheat sheets with highlighted decision paths, we come to the conclusion that Team Foundation Service is a good deployment model.

We probably need one Team Project Collection and one Team Project for the mainstream ALM Ranger solutions. Each solution, project and initiative would be isolated in terms of a specific Team, owning its own backlog and area path.


The experimentation team project,in our new world would potentially look like:


Default Team

Let’s define the iterations and associate the area for our default, core team. Note that the “Black Hole” iteration spans both Team X and Team Y sprint. We start when the first team starts and finish when the last crosses the line.

image  image

Team X

We do the same for Project X …

image  image

Team Y

… and finally for Project Y.


Test Data

Our test data is simple. We create a few Epics and one task for Project X and two tasks for Project Y.


Team X View

If we switch to Team X we get the familiar and informative home page. Switching to the board, we see the only task we created for project X.


Team Y View

In the project Y world we see one of the two tasks we created for the team, which falls within Sprint 1.


Consolidated Board View

If we switch to the default team, we see the correct accumulated 9 hours, but as expected see no burn down. Switching to the board, however, we suddenly see all the tasks which are being worked on by team X and Y.


The advantages we see in the single TPC and single TP model are:

  • As Gregg mentions in Team Foundation Service Preview – Configure a master backlog and sub-teams, we will have one backlog to rule them all Smile
  • We will drill into specific projects and sub-team backlogs, board and status, or switch to an overall view.
  • We will have less context (team project) switching needed by ALM Rangers working across multiple projects.
  • We will be able to share and re-use queries easier amongst the various teams.

The disadvantages we are pondering over:

  • It will be like merging a few teenager caves into one room. We will have to be proactive in terms of avoiding messy or non-actionable backlogs.
  • When a project is cancelled the deletion of its state will not be as easy as running the tfsdeleteproject command.
  • Would be “cool” to see a burn down for Consolidated (default) View as well … pondering over optionsat the moment.

Thoughts? What do you think of our new single Team Project Collection and Team Project suggestion?

Comments (4)
  1. Allen Feinberg says:

    Your disadvantages are all wrong:

    •It will be like merging a few teenager caves into one room. We will have to be proactive in terms of avoiding messy or non-actionable backlogs.  ANSWER – Use areas and iterations and TFS Security to restrict access. Security and Active Directory Groups will be your friend look here:…/b40cebfb-3a35-468e-b147-021fd3824a77

    •When a project is cancelled the deletion of its state will not be as easy as running the tfsdeleteproject command. ANSWER – tfsdeleteproject is a cop out. When a project is cancelled just move the area/interation under a hiearchy called canceled.

  2. Allen, thanks for the candid feedback.

    A core principle within the ALM Ranger family is that everyone has access to everything, which means that we cannot and will not restrict access. It is therefore important that we define and adhere to a common and consistent modus operandi within the team project, otherwise the environment will very quickly resemble the rooms of my sons 🙂

    I disagree that tfsdeleteproject is a copout. By moving a Team Project to another Team Project Collection for safekeeping and then deleting it from the operational environment has reduced resource usage, possible confusion with orphaned content and allowed us to keep our backyard tidy and simple.

    As highlighted in our planning guide there is no silver bullet, but a menu of options from which we can select the ingredients that allow us to implement an environment that works for us.

  3. Allen Feinberg says:

    "everyone has access to everything, which means that we cannot and will not restrict access." You can grant read, but restrict write to the rangers involved in the specific project. Are you already adding all TFS Rangers to all TFS Projects?

    I'll agree with "no silver bullet" but there are less bad options. 1 Team Project is the best bad option. 🙂

  4. We are aware of the granular security model in TFS 🙂 … but as mentioned every ALM Ranger has (full) access to everything, which include our Team Projects.

Comments are closed.

Skip to main content