My 2 cents on Areas and Iterations in Team Foundation Server

There’s not a huge amount of best practice info out there regarding areas and iterations.  One interesting place to look at is a blog post that describes how the Visual Studio team uses them (


So here are my 2 cents (you can see how much that's worth these days!) on Areas and Iterations. 



To me, areas are ways of tagging or organizing objects within a Team Project.  Typically, areas are used to define either logical, physical, or functional boundaries.  It’s a way to slice and dice a normally large project effort into more manageable, reportable, and easily identifiable pieces. 


For example, let’s say we have a tiered web application managed in a single TFS project called “MySite”.  There are 3 major components to this app:  the web site, a web service, and a database.  If this is a decent-sized application, you might have 1,200 tasks in the system for this project.  But how do you know to which component a given task belongs?  What if I only wanted to see tasks for the web service piece?  Areas are a convenient way to handle this.  Set up areas like this:



   \Web Site

   \Web Service



Now you can specify an area of assignment for each task (work item), making it easy to effectively filter what you want to look at/work on.  You can use areas in both queries and reports as well.


You may optionally want to further dissect those major components to be even more specific:



   \Web Site

      \Layout & Design



         \Contact Us



   \Web Service








One final aspect of Areas to consider is security.  You can set security options on each Area node which can dictate not only who can change the areas, but also who can view or edit work items in a particular Area.



So if you think of Areas as slicing and dicing by “space”, think of Iterations as slicing and dicing by “time”.  Iterations are like “phases” of a lifecycle, which can dissect the timeline of a project effort into more manageable time-based pieces. 


So going back to the “MySite” example, say the project management team wants to split the entire project into 3 cycles, Phase 1, Phase 2, and Phase 3.  Thus, your Iterations can mirror that:



   \Phase 1

   \Phase 2

   \Phase 3


These Iterations can be phases within the entire life of a project, or phases within a given release of a project.  So if “MySite” is going to have multiple releases over time, my Iterations might look lik this



   \Release 1.0

      \Phase 1

      \Phase 2

      \Phase 3

   \Release 2.0

      \Phase 1

      \Phase 2

      \Phase 3


Now you have categorization options for both space and time (now if only we had a continuum..) for your project, allowing you to assign your tasks or other work items not only to the appropriate functional area (Area), but also to the phase (time cycle) of the project.

Comments (31)
  1. Steven Lange says:

    @Lionel – you can either use some security settings to filter what that person can see, or you can take advantage of the "team" concept in TFS to let team resource (individual or several people) have their own backlogs, queries, dashboards, etc.

    More here:…/multiple-teams

  2. Lionel says:


    How do we assign a given team member (resource) to an area so as he/she will see only tasks and bugs linked to that area ?

  3. Anil Bhide says:

    Your post exactly explains the usage of Area and Iterations – exactly what I was searching for

  4. Nidhi says:

    Nice 1… excellent discription….

    nowhere i found this much good explanation about area and iteration….

  5. Baskar says:

    Awesome explanation !

    Thank you ..

  6. Thanks, nice over view of areas and iterations. Now to go make my own 🙂

  7. Steven Lange says:

    @Dave – they can be redundant if you want them to be.  However, the souce tree structure doesn't always represent the functional hierarchy or structure of a project.  Letting areas be an independent field provides more flexibility when working with work items.  

    The main intersection (IMHO) between the source control structure is with Iterations.  Yes, you can replicate Iterations with your releases/branches in source control.  In Iterations, you can even further dissect releases into sprints, etc. to better help track progress for a given release.  

    Work items are associated with code in two ways:  by linking (work item to changeset or versioned item), or by build (completed work items are associated with a build).   Because of these other manners to align the two types of artifacts, you are free to use Areas & Iterations as you see fit – either closely mirroring the source tree, or in a more logical hierarchy that makes sense for your reports, and your business.

    Hope this helps a little..

  8. Dave says:

    Seems to me that areas are redundant with the source project organization and iterations redundant with release versions. How are areas and iterations supposed to work in conjunctions with the source tree organization for branching? Thanks!

  9. rnysuen says:


    Let say I have the following Iteration tree:


       Release 1

         Phase 1 – Aug 1-15, 2010

         Phase 2 – Aug 16 – 30, 2010

         Phase 3 – Sept 1 – 15, 2010

         Phase 4 – Sept 16 – 30, 2010

     Release 2

       Phase 1 – Oct 1 – 15, 2010

       Phase 2 – Oct 16 – 31, 2010

    And some urgent bug from customer and we need a hotfix for Release 1 while Release 2 development is on going. How should I capture and plan for the hotfix effort? Should I

    i) create MySiteRelease 1Phase 5 – Oct 16 – 31, 2010 so that it'll have the same time frame as MySiteRelease 2Phase 2 – Oct 16 – 31, 2010

    ii) include work items in Release 2 -> Sprint 2 – Oct 16 – 31, 2010 (will have to distinguish the work items somehow?)


  10. obautista says:

    I hope you can help me.  We have set up permissions on Areas and Iterations within each Team Project.  We have multiple levels of Areas and Iterations.  For example, we have a Parent Iteration, a Child, and a Sub-Child.  When I assign permissions to Jane Doe to Parent Iteration she does not get access to Child and Sub-Child.  Is this correct?  I was thinking assigning permissions to Parent should give her permissions to Parent and everything underneath (children).

    Thanks for any help you can provide

  11. Steven Lange says:


    Are you asking how you can add iterations in bulk?  I would definitely not recommend going directly into the TFS database.  

    One option would be to use the SDK.  

    You’ll want to do so using the ICommonStructureService.CreateNode method in the TFS SDK:

    This post should help you get started:

    However, depending on how many iterations you want to add, it may just be more time-efficient to enter them manually.

    Hope this helps!

Comments are closed.

Skip to main content