Hi Shelby,

We are trying to collect answer for your above concern.

Your question involve 4 concepts in RTC:
Project Area, Team area, Development Line and Iteration Plan.

In one Project Area, you can have multiple Development Lines.
For each development line, you can have multiple team working on it.

You then can create iterations under specific development line and assign iteration plan to associated team area.
because team area to development line is a multi -> one relationship, so create iteration plan within a team area is a easier way, I think.
Please refer to information center for more details.
https://jazz.net/help/rational-team-concert/1.0.1/index.jsp

So far, there is some defect in this area, causing mismatch between development line, iteration plan and team area.
Please refer to defect 75289.
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=75289

An "iteration plan" is the place where you view and modify the work for
a given team for a given iteration. A team is specified in a team area,
so that is why when you "configure" an iteration plan, you specify a
team area ("the team") and an iteration.

Then the question is, what work items appear in a give iteration plan?
In RTC, the answer is "it's the result of a work item query". In
particular, it is all work items such that:
- Planned-For field specifies the iteration of that plan
- Filed-Against field specifies a category that is associated with that
team area

The benefit of this approach (as opposed to just having a
work-item/iteration-plan link) is that:
- as soon as a new plan is created, it is automatically populated by the
appropriate work items
- changes to the appropriate fields automatically update the appropriate
plans.

So if you set the Filed-Against field, it will automatically move the
work-item from the old plan it was in, to the new plan (and re-calculate
all the loads). Similarly, if you change the assignment of a category
to be a different team-area, it will automatically move the work-items
to the appropriate plan.

So you don't assign a work item to a team area ... the team area is
inferred/computed from the filed-against field and the planned-for field.

One feature that sometimes is confusing is that the mapping (in the
project area) from category to team-area can be made relative to a
development line (in 2.0, called a "timeline"). So you can say that in
the primary-development line, a category is mapped to one team area,
while in the maintenance line, it is mapped to a different team area (in
case there are different development teams and maintenance teams for
that category).

Cheers,
Geoff


shelbyph wrote:

Could you please explain the dependency of Iteration Plans to Team
Areas?

I have noticed that Iteration Plans are tied to specific Team Areas
upon creation. However, it is possible to assign Work Items within a
iteration to a different Team Area than the Iteration
Plan is tied to via the "Filed Against"
field.

I am trying to understand why I would want to tie an iteration plan to
a specific Team Area instead of the Project Area.

It will show up in neither of those plans ... the conditions are "AND"ed
together, i.e. for a workitem to show up in Plan X, the category that it
is filed against must be associated with the team area of Plan X *and*
the iteration that it is planned for must be the iteration of Plan X.

So this workitem would only show up in iteration plan for Iteration: A
and Team Area: Y.

Cheers,
Geoff

shelbyph wrote:

Thanks for all the clarification.

As an end user, the confusion seems to be the potential conflict
between the scenario below, where a Work Item is "Planned
For" Iteration A, and "Filed Against" Category Y.

Would this show up in Iteration Plan A or B? Which has precedence?

Category Y = Team Area Y
Category X = Team Area X

Iteration Plan A
Iteration:A
Team Area: X

Iteration Plan B
Iteration: B
Team Area: Y

Work Item A
"Planned For": A
Filed Against: Category Y