ADO Area Paths vs. Iteration Paths

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.

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.