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.

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

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

Comments

[markom]

Can you show me an example of iterations that you have defined?

[markom]

Thank you! Now it's a bit clearer. We used iterations based on specific milestones in our project, and now, we're in constant and never ending support iteration which is obviously wrong... :)

[Gregory A Beamer]

Yes, I do. But that is common for Agile. If you do not time box an iteration, then you end up both time boxed (as management gives dates all the time) and feature boxed. You also generally are resource boxed, which means you must deliver X by Y with Z developers. A death march! ;-)

[TestyTest]

your jpg-link is broken, can you fix it?

[Kevin Babcock]

@Patrick: Sorry about that...moved servers and somehow that image got left behind...here's a new link bit.ly/9x5t8y