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 (http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx)

 

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

 

Areas

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:

 

MySite

   \Web Site

   \Web Service

   \Database

 

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:

 

MySite

   \Web Site

      \Layout & Design

      \Navigation

      \Pages

         \Contact Us

         \Homepage

         \Links

   \Web Service

      \Performance

      \Security

   \Database

      \Performance

      \Security

      \Schema

 

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.

 

Iterations

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:

 

\MySite

   \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

 

\MySite

   \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.