Hello Roman,

you define categories within a Project Area. You can associate a Team
to a categorie that is valid for all development lines.

You do not have to duplicate the categories when you start a new
Development line like Maintenance. But you can associate another Team
to the Categorie within the Maintenance and at the same time you can
keep tha associated teams for the Development.

You can read more about defining Categories on:
http://publib.boulder.ibm.com/infocenter/rtc/v1r0m0/index.jsp?topic=/com.ibm.team.workitem.doc/topics/t_defining_categories.html

Does this answer your question?

/Elisabeth

You can associate the category with a team area for each development line.
E.g., you would change the 'development line' switcher in the category
editor page to Support Line and then associate Environment with the
Support team. That association will be used for work items being planned
for an iteration of the Support Line. The associations shown when the
development line switcher is set to <any> only determines the default for
development lines that have no specific team area associated. (Note that
changing the categories' team association affects existing work items and
therefore can move them to other iteration plans.)

Regards,

Christof
Jazz Work Item team


Roman Smirak wrote:
Hi Elisabeth,

I disassociated a category (let's say Environment) with a team area
and it gets associated with parent team area which is the
development team. If I create a work item and associated with the
category Environment and current support iteration (Support line) then it
gets excluded from Planned items of the support iteration. I have to
associated the category with the Support team to see it as the planned
item of the support iteration plan.

Any advice?

Roman

"ehodel" <elisabeth> wrote in
message news:g771af$slu$1@localhost.localdomain...
Hello Roman,

you define categories within a Project Area. You can associate a Team
to a categorie that is valid for all development lines.

You do not have to duplicate the categories when you start a new
Development line like Maintenance. But you can associate another Team
to the Categorie within the Maintenance and at the same time you can
keep tha associated teams for the Development.

You can read more about defining Categories on:
http://publib.boulder.ibm.com/infocenter/rtc/v1r0m0/index.jsp?topic=/com.ibm.team.workitem.doc/topics/t_defining_categories.html

Does this answer your question?

/Elisabeth

Here you would configure the associations between categories and team
areas on the Work Item Categories page of the project area editor as
follows:

1) With the development line switcher on the page set to <any> (this will
capture work items with no Planned For iteration set): associate the
categories with the Dev team
2) Line switcher set to Dev line: categories are already associated to Dev
team from step 1)
3) Line switcher set to Support line: associate categories to Support team

With this you would create iterations plans for both teams, an iteration
plan is always scoped to a single development line (given by the team area
which can only have one development line).

HTH,

Christof
Jazz Work Item team


Roman Smirak wrote:
Hi,

I'm not sure I got it.

I would see scenario:
Let's have two development lines: Dev, Support
Two teams: Dev, Support
The teams are associated with appropriate line (can one team serve both
lines?)
Categories: Content, Training, Environment, Internal, ...

Expected behaviour: I can associate a work item with Content category for
Dev line iteration as well as Support line iteration plan.

Current behaviour: if I associate a work item planned for Support
iteration with Content category then it disappears from the iteration
plan.

Regards,

Roman

"Christof Marti" <christof_marti> wrote in message
news:g78t3a$mds$1@localhost.localdomain...
You can associate the category with a team area for each development
line. E.g., you would change the 'development line' switcher in the
category editor page to Support Line and then associate Environment with
the Support team. That association will be used for work items being
planned for an iteration of the Support Line. The associations shown
when the development line switcher is set to <any> only determines the
default for development lines that have no specific team area
associated. (Note that changing the categories' team association affects
existing work items and therefore can move them to other iteration
plans.)

Regards,

Christof
Jazz Work Item team


Roman Smirak wrote:
Hi Elisabeth,

I disassociated a category (let's say Environment) with a team
area and it gets associated with parent team area which is
the development team. If I create a work item and associated with the
category Environment and current support iteration (Support line) then
it gets excluded from Planned items of the support iteration. I have to
associated the category with the Support team to see it as the planned
item of the support iteration plan.

Any advice?

Roman

"ehodel" <elisabeth> wrote in
message news:g771af$slu$1@localhost.localdomain...
Hello Roman,

you define categories within a Project Area. You can associate a Team
to a categorie that is valid for all development lines.

You do not have to duplicate the categories when you start a new
Development line like Maintenance. But you can associate another Team
to the Categorie within the Maintenance and at the same time you can
keep tha associated teams for the Development.

You can read more about defining Categories on:
http://publib.boulder.ibm.com/infocenter/rtc/v1r0m0/index.jsp?topic=/com.ibm.team.workitem.doc/topics/t_defining_categories.html

Does this answer your question?

/Elisabeth

Roman Smirak wrote:
Hi,

did I understand correctly:
1. You can associate a category with only Team area
2. A team area can be associated with only Development line
3. Project plan shows work items associated with parent line
=> A work item associated with a category associated with the dev team
won't be ever visible in an iteration plan of the support team


Regards,

Roman


Perhaps an example will help here. Or maybe not as this is getting long as
I detail it...
- The Jazz project has two development lines: "development" and "Post 1.0
Explorations".
- For this example, lets look at two categories defined for the Jazz
project: "Agile Planning" and "Dashboards".
- On the "Work Item Categories" page of the Jazz project editor and with
the and with the development line set to "<any>" (this sets the default
mapping of categories to team areas), you would notice that the "Agile
Planning" category is associated with the Agile Planning team from the
"development" line and that the "Dashboard" category is associated with
the Dashboard team from the "development" line. It is possible to create a
default association to any team in any development line.
- If you were to change the development line chooser on the "Work Items
Categories" page to the "development" line, you would see the same
associations and it would be noted that they are the default associations
that were created when we had the chooser set to "<any>". We could
override some of these here but not yet...
- If you were to change the development line chooser on the "Work Items
Categories" page to the "Post 1.0 Explorations" line, you would see that
the association for the "Agile Planning" category has been overridden from
the default to be associated with the "Agile Planning Explorations" team
from the "Post 1.0 Explorations" line. You would also see that the
"Dashboard" category has not been overridden and still is associated with
the Dashboard team from the "development" line.

NOTE: At this point, you may want to try to configure your categories is a
manner similar to what I described above. That will help you follow along
live with the next bit. That is:
- Two categories with a default mapping to two teams on your main
development line ("Work Item Categories" page line chooser on "<any>").
- An override of the association of one of those categories to a team
area on your support line ("Work Item Categories" page line chooser on
your support line).

Now, lets create a couple new work items:
- Create a new defect and set the "Filed Against" field to "Dashboards"
(or your similar category that does not have an overridden association to
a team area). It will be mapped to the Dashboards team (or your
equivalent).
- Now set the "Planned For" field to an iteration from the main
development line and note that the team area does not change.
- Now set the "Planned For" field to an iteration from the support line
(or the explorations line, if we were doing this on the Jazz project) and
again the team area does not change since the default association is
always applied. Not too interesting yet and not too helpful for planning
since you can only create plans for a combination of iteration and team
area that are part of the same development line.
- Now close that work item editor without saving and open another new
work item just to make sure you are starting fresh.
- Set the "Filed Against" field to "Agile Planning" (or your similar
category that does have an overridden association to a support team area).
It will be mapped to the Agile Planning team from the main development
line (or to your equivalent). This is because this is the default
association for the category and we have not provided any information to
indicate anything else.
- Now set the "Planned For" field to an iteration from the main
development line and note that the team area does not change. This is as
expected since the main development line does not override the
association.
- Now things get a bit more interesting. Set the "Planned For" field to
an iteration from the support line (or the explorations line, if we were
doing this on the Jazz project) and note that the team area DOES change to
the team indicated in the association override (the "Agile Planning
Explorations" team if we were doing this on the Jazz project). This is
very interesting and very useful for planning. You can have plans for both
the main development team and the support team and the work items will
move between the proper plans as you change their iteration targets. All
while your work item submitters use a single set of categories!

This is why you can just create teams on your support line as you need
them. You do not have to duplicate your full team structure as soon as you
branch. Let the incoming work items collect using the defaults and once
you decide you need to fix some on the support line, then create the
responsible team on the support line, override the category association on
the support line, create the team's stream from the proper
snapshot/baselines and start targeting work items to a support iteration.
And it all just works right! The items will show up in the proper plans.

Note that if you are going to apply a fix to both lines, that can be
managed a number of ways. One common one is to create a work item for each
line (different planned iterations but the same category) and give them a
relationship link (a lot of teams use parent/child links for this). If you
use parent/child, the relationship will show up nicely in both plans (main
line and support).

I hope this helps and was not to long or detailed to follow.

Steve Wasleski
Jazz Jumpstart