Steve Lange @ Work

Steve Lange's thoughts on application lifecycle management, Visual Studio, and Team Foundation Server

My 2 cents on Areas and Iterations in Team Foundation Server

My 2 cents on Areas and Iterations in Team Foundation Server

Rate This
  • Comments 27

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.

Leave a Comment
  • Please add 1 and 8 and type the answer here:
  • Post
  • "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."

    How! I've been searching for hours and can find no instructions 'HOW to assign work items to areas and iterations'.

    As an alternative, if I was using some sort of RUP like process I might want to assign disciplines to areas (Business, Requirements, etc) and phases to iterations (Inception, Elaboration, Construction, Transition).

  • Leslei -

    You set the area and iteration in the Area Path and Iteration Path fields.

    In this example, the Task work item type in the MSF for Agile process template displays the Area and Iteration fields in the Classification.

    See this image:

    Once you set this, you can filter reports based on the area or the iteration to report on a particular cross-section of your project's work items.  

    Regarding your RUP-like idea, that should be just fine.  However, by default work items can also leverage a built-in Discipline field (you'll find it in the same image above, at the top-right of the dialog), which can be customized to represent the disciplines of your choice.  And you definitely can map iterations to phases if you want (or it you want further granularity, you can create a custom "Phase" field).

  • so how and where do I create these customized sub-areas? All I can see is the name of my team project...

  • You can edit your areas (ie create sub-areas) and iterations (ie create multiple/sub-iterations) from the Team Explorer panel.

    In Team Explorer, right-click on your project and select Team Project Settings -> Areas and Iterations.  This will bring up the Areas and Iterations dialog where you can add/edit/delete areas and iterations for this project.

    (Just note that areas and iterations are cached on the client side, so once you make changes here, you'll want to click the Refresh button at the top of the Team Explorer panel to be able to use your changes immediately.)

  • Looks like yours is the most informative blog entry on Areas and Iterations.  Hopefully you can help me.

    It seems wrong that Areas and Iterations sort alphabetically in the Work Item drop-downs.  I initially spent time sorting them how I wanted them in the A&I dialog, only to find them all scrambled up when I actually tried to apply them in a WI.

    So what good does ordering them in the dialog do?  And is there a way to get that ordering to be used in the drop-downs for Work Items?

    Any insight you could provide would be appreciated!

  • I agree that it's a pesky, annoying thing that areas & iterations are listed alphabetically.  I can't even give you a great, eye-opening explanation as to why it's this way.  I would expect this to be updated/fixed at some point.  

    As a workaround, I'd suggest prefixing your areas & iterations with numbers so they order the way you want.  Not elegant, but it's doable.

    I'll update the post when I hear that this is getting updated.

  • Thank you for very nice explanation about Area and Iteration. Really helpful!

  • Hi slange,

    I can not see the image you have left its link on your comment.

    By the way, I found your article very useful, thanks,


  • You're right, that link in the comment is gone.  That site was taken down a while back and I couldn't get to the content prior.

    The was basically a screenshot showing a work item dialog with the Area and Iteration fields highlighted.

  • Great post, it's exactly what I search. There are no realy good samples into the tfs's doc.


  • That was the best description regarding Areas and Iterations, I found.


  • You're very welcome.. I'm glad to see that this post is helpful over two years after it was first posted!

  • Can you let me know how to add mulitple levels ?

    I need to add this :







    I can add the Request nodes, but I can't work out how to add the Response element ?

  • Hi Tim,

    You have to have a single root Area node, so my suggestion would be to do something like:








    Does that make sense?

  • Your post is still helpful ofcourse,but can you tell if there has been any changes to the Iteration Path in TFS2008, is there any way of sorting the values non-alphabetically yet?

Page 1 of 2 (27 items) 12