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.
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:
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:
\Layout & Design
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:
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
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.
FYI - The issue with Areas and Iterations (sorting) does not seem to occur with Team Explorer 2008 (sp1 applied).
BTW - This post has been very informative on the issue of Areas and Iterations. Thanks!
Helpful post and I can see how it could be helpful to our group as we have many small projects which dont all necessarily need a separate Team Project.
But what I am not able to figure out is how do I customize the reports to see information only assigned to a particular area. (I am using the Scrum for TFS template - and it has an option for filtering by iteration, but not by area). Are there any MS supplied templates that will allow me to view my reports by area and iteration.
Thanks again for your helpful post.
Denver Area TFS user
Thank you very much slange for this very useful post.
So helpful post!! I learned a lot from this "simple" post.
Thank you very much, slange!
By the way, happy Thinksgiving!
how do you add multiple iteration dates at once? our iteration structure is as follows:
can I do this directly in the TFS database?
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: http://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.server.icommonstructureservice.createnode.aspx
This post should help you get started: http://teamfoundation.blogspot.com/2008/09/how-to-deal-with-areas-or-iterations.html
However, depending on how many iterations you want to add, it may just be more time-efficient to enter them manually.
Hope this helps!
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
Let say I have the following Iteration tree:
\Phase 1 - Aug 1-15, 2010
\Phase 2 - Aug 16 - 30, 2010
\Phase 3 - Sept 1 - 15, 2010
\Phase 4 - Sept 16 - 30, 2010
\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 \MySite\Release 1\Phase 5 - Oct 16 - 31, 2010 so that it'll have the same time frame as \MySite\Release 2\Phase 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?)
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!
@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..
Thanks, nice over view of areas and iterations. Now to go make my own :)
Awesome explanation !
Thank you ..