Using Areas and Iterations in Team Foundation Server 2008

Question

If you are using TFS 2005 or 2008, how do you user iterations and areas?

Do you create an area for specific parts of the application you are building?

Here is an interesting article on areas and how the TeamSystem team uses them:

http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx

But, i'm even more curious about iterations and I would be grateful if you could show me few concrete examples.

Do you create iterations based on milestones or based around certain functionality?

What happens when you finish v1, how do you manage v2 or updates to v1?

We are using MSF Agile template.

Answer 1

We use areas to represent product lines.

Since we use SCRUM, the iterations in TFS are used to define our release cycles, and the sprints within those release cycles. Backlog items are assigned to release cycles and work items are assigned to eash sprint to ensure those backlog items are completed. After a release, it is perfectly fine to add bug fixes/updates to the backlog while working the next version at the same time.

Answer 2

I assume you are using iterations as part of MSF Agile, or some other type of Agile methodology. If so, in general, you figure out how much work can be completed by your team over the next n weeks. In general, we used 3 weeks, but your iteration length may be different.

How you determine the items for the iteration is generally based on priority, which should be based on market/business impact (hotness of item) and ease of implementation. The impact score is the heavier weight, but you should consider ease of implementation in your score as you may have a few "bang for the buck" items.

The rule, with Agile, is features that cannot be completed get dropped. You NEVER extend an iteration date.

This should answer the milestones versus functionality question. It is neither. You base an iteration on time. It is time boxed. This way you can figure how optimistic your team is an adjust next iteration to get more accurate on estimates. If you base an iteration on functionality, you will always miss dates. The same is true for milestones.

NOTE: If you are talking waterfall, the rules can be based on milestones and functionality, but with Agile, time is king.

Now to areas: This one is more subjective. One way of dividing into areas is grouping use cases. I like this method. But, when it comes to user interface, you can also create areas for particular forms, etc.

Answer 3

The Iteration and Area Paths are what you want them to be. Its how you can describe your project in space and time. An easy example are as follows:

Area Path (Space) - can be used to describe the parts of your system/project. Say you create a TeamProject for a GUI application, some areas will discribe its modules (Data Input, Reports, GUI, Printing, etc...)

Iteration Path (Time) - describes Versioning or Release Cycles of your project. On company that I worked for used release versions as their iterations (major, minor, build, revision). It helps track the work items to mark what iteration it was expected to be completed by. We had a static TBD iteration which was the default for all work items created. Management would decide later where to target that work items and assign them or close them.