Agile Journey – TFS Area Paths vs. Iteration Paths

We’ve been progressing on our journey towards a higher degree of Agile, and the tool that we’ve been using historically is Microsoft TFS (currently upgraded to version 2017 Update 2). We have a multitude of teams that work on the same product, for the same release, but on different projects/features. Sometimes a team will be working on multiple releases (that are at different stages in their life cycle), or a project (if it’s big enough) may involve multiple (Scrum) teams.

TFS, from an Agile perspective, has been challenging to adapt. So with a very large initiative that we have under way, for a multi-team effort, the team took the approach of Area Path=\Project X, with Iteration Paths = \Project X\Sprint Y. Which led to some confusion in that it seems duplicative in that if you want to measure the project burn down, if all work items are under the Project X iteration path, why bother setting and querying off the Area Path as well.

The shift that we’re making is to adjust the Iteration Paths to be less about the project, and more about the (Scrum) team(s).

1. Iteration Paths are meant purely for planning (it answers: when, i.e. time).
   1. What work did we do in the past.
   2. What work are we doing now.
   3. What work are we planning to do next.
   4. For an Agile team, it’s just a list of Sprints.
   5. A team could be working on a multitude of products and features on any given Sprint.
      1. To add to that, there are multiple active releases in various different stages of their life cycle.
   6. Additionally
      1. It’s hugely valuable for all teams to adopt a standard convention for team centric iteration pathing so that we can automate the calculation & visualization of KPIs.
      2. Likewise, we want to continue to build the culture around long-lasting-persistent-teams (vs. transient project centric teams).
         1. A key clarification is that the team isn’t name after the project, that would make it transient. The team names last in perpetuity (I’ll admit that word has stuck with me from Kevin O’Leary using it so often on Shark Tank), giving them a sense of identity and unity.
      3. Thus, the following iteration path model is what we’ve gravitated towards:
         1. Team A\
            1. Sprint 1
            2. Sprint 2
            3. Sprint 3
         2. Team B\
            1. Sprint 1
            2. Sprint 2
            3. Sprint 3
         3. Etc…
2. Areas Paths  (it answers what)
   1. What product.
   2. What feature.
   3. What component.
   4. What project.
   5. Etc…
3. Target Version (a custom field)
   1. Because of point 1.5 above, we can differentiate the total scope of the project vs. the way a release is measured via the Target Version.
   2. It’s the simplest way to derive what are all the things that add up to the Release, allowing us to burn down all the scope that makes up a Release, and forecast its completion.
   3. Noting that a project may be released across multiple Releases (that would be ideal actually – that way you can start getting some early feedback). So although you may have an Area Path for the product/project/feature, the Target Version makes it easy to discern what’s targeted for which Release.
      1. Other teams might approach this via Release X\Sprint Y iteration path conventions, which we’ve tried, but doesn’t work because of point 1.5 above.