It's all about the answers!

Ask a question

Team areas, categories and WIs (again?)


Thomas Cherel (762) | asked Dec 06 '11, 12:22 p.m.
Hi,

I am trying to figure out the right setup between the team areas, the categories and the WIs for our development organization.
I went through the following article https://jazz.net/library/article/589/ and I am a little troubled by the 1:1 association between WI categories and team areas.
Le me explain:

- We have two team areas under the same project area. Let's say a dev team and a CE team.
- Each team is working within its own time-line(s) and iterations.
- But each team are also working on the same product components. For example, both team are working on the same web UI. Dev to add new features, CE to fix bugs in previous releases of the UI. It seems to suggest that the categories for both teams should be the same but since a category belongs to only one team, it is not possible.

I was hoping that the same category can be used by multiple teams and only the assignment of the WI to a specific iteration will really determine which team is working on which WI (which team is "owning" the WI).

Should I consider duplicating the categories?
Something that I did not try is to create a team hierarchy: having a "super" team, parent of the dev and CE team and associate the category to that parent team. Will that work? If it will, any specific side-effects that I should be aware of?

Thanks.

7 answers



permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 06 '11, 1:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The first thing you will want to do is to understand that the purpose of
the "category" tree is just to automate the routing of a submitted work
item to a team that is responsible for it. If your teams work on
certain features of the product, then you can have those features as
your categories (and define those feature-categories to be mapped to the
team response for those features).

But if your teams are partitioned by releases rather than by features,
then your categories should be releases (not features).

Cheers,
Geoff

On 12/6/2011 12:23 PM, tcherel wrote:
Hi,

I am trying to figure out the right setup between the team areas, the
categories and the WIs for our development organization.
I went through the following article
https://jazz.net/library/article/589/ and I am a little troubled by
the 1:1 association between WI categories and team areas.
Le me explain:

- We have two team areas under the same project area. Let's say a dev
team and a CE team.
- Each team is working within its own time-line(s) and iterations.
- But each team are also working on the same product components. For
example, both team are working on the same web UI. Dev to add new
features, CE to fix bugs in previous releases of the UI. It seems to
suggest that the categories for both teams should be the same but
since a category belongs to only one team, it is not possible.

I was hoping that the same category can be used by multiple teams and
only the assignment of the WI to a specific iteration will really
determine which team is working on which WI (which team is
"owning" the WI).

Should I consider duplicating the categories?
Something that I did not try is to create a team hierarchy: having a
"super" team, parent of the dev and CE team and associate
the category to that parent team. Will that work? If it will, any
specific side-effects that I should be aware of?

Thanks.

permanent link
Thomas Cherel (762) | answered Dec 06 '11, 3:15 p.m.
Thanks Geoff.

I guess I want both :-)
I want to partition both by release and by feature.
The dev/CE split is really a split by release (the release time line/schedule for the dev team is not the same as the CE team one).
But within the dev team or the CE team, I might want to further partition by feature.
But may be I am over-thinking it :-)

I have the impression that categories should really be components. If I start using categories as releases, then it starts to duplicate the notion of "planned for", I think.

Do you think that the hierarchical team feature will work? I think I am going to try that. When new WI are created, there is anyway a triage activity going on to decide who should take care of it so I am not sure that the automation of the team routing through the categories is that useful to me.

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 06 '11, 5:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
There is a strong tendency of folks to want the "categories" to mean
something other than "the thing that automatically assigns a new work
item to the right team". Resist that tendency (:-). That is all that
categories are there for.

Also note that the "right team" is the team that should first look at
the work item. So if you have one team that triages all of your work
items, then your category list is very easy ... it just has one entry in
it, and that category is mapped to the team area that is doing the
triage. And in that case, if each of your releases has its own
timeline, then you can avoid duplicating the releases in the category
list. Just map that category to the appropriate team for the
appropriate timeline (you can map the same category to different teams,
as long as each team is in a different timeline).

Cheers,
Geoff


On 12/6/2011 3:23 PM, tcherel wrote:
Thanks Geoff.

I guess I want both :-)
I want to partition both by release and by feature.
The dev/CE split is really a split by release (the release time
line/schedule for the dev team is not the same as the CE team one).
But within the dev team or the CE team, I might want to further
partition by feature.
But may be I am over-thinking it :-)

I have the impression that categories should really be components. If
I start using categories as releases, then it starts to duplicate the
notion of "planned for", I think.

Do you think that the hierarchical team feature will work? I think I
am going to try that. When new WI are created, there is anyway a
triage activity going on to decide who should take care of it so I am
not sure that the automation of the team routing through the
categories is that useful to me.

permanent link
Thomas Cherel (762) | answered Dec 06 '11, 5:44 p.m.
Understood.
I actually completely missed the fact that the categories could be mapped on a per item AND time line basis.
I thought the category/team mapping was time line independent hence my "issues".
With the mapping per team and time line, I believe I can do exactly what I want: a set of categories shared by multiple teams, each team working in its own iteration.

Thanks a bunch for the input.

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 07 '11, 1:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
In the Web Browser, in the categories pane in the Project Area
Administration page, there is a Timeline box whose default value is
"(any)". Change that timeline value to a specific timelines, and then
you can map categories to team areas just for that timeline.

Very similar for the Eclipse UI project area editor.

Cheers,
Geoff

On 12/7/2011 11:23 AM, thloeber wrote:
gmclemmwrote:
There is a strong tendency of folks to want the
"categories" to mean
something other than "the thing that automatically assigns a
new work
item to the right team". Resist that tendency (:-). That is
all that
categories are there for.

Also note that the "right team" is the team that should
first look at
the work item. So if you have one team that triages all of your
work
items, then your category list is very easy ... it just has one
entry in
it, and that category is mapped to the team area that is doing the
triage. And in that case, if each of your releases has its own
timeline, then you can avoid duplicating the releases in the
category
list. Just map that category to the appropriate team for the
appropriate timeline (you can map the same category to different
teams,
as long as each team is in a different timeline).

Cheers,
Geoff


On 12/6/2011 3:23 PM, tcherel wrote:
Thanks Geoff.

I guess I want both :-)
I want to partition both by release and by feature.
The dev/CE split is really a split by release (the release time
line/schedule for the dev team is not the same as the CE team one).
But within the dev team or the CE team, I might want to further
partition by feature.
But may be I am over-thinking it :-)

I have the impression that categories should really be components.
If
I start using categories as releases, then it starts to duplicate
the
notion of "planned for", I think.

Do you think that the hierarchical team feature will work? I think
I
am going to try that. When new WI are created, there is anyway a
triage activity going on to decide who should take care of it so I
am
not sure that the automation of the team routing through the
categories is that useful to me.

How do you map s single category to more then one team? I'm not able
to do that even though the two team are on different timelines.

permanent link
Thomas Cherel (762) | answered Dec 06 '11, 3:32 p.m.
Ok, it seems that hierarchical team is not going to do it.
First, it seems that a child team cannot work on a different iteration from the parent team.
Second, it seems that the assigned categories are not inherited by the child team: if a category is associated to a parent team, that category is not associated to the child team as well.

I guess I will have to duplicate categories.....

permanent link
Thomas Loeber (62237750) | answered Dec 07 '11, 11:16 a.m.
JAZZ DEVELOPER
There is a strong tendency of folks to want the "categories" to mean
something other than "the thing that automatically assigns a new work
item to the right team". Resist that tendency (:-). That is all that
categories are there for.

Also note that the "right team" is the team that should first look at
the work item. So if you have one team that triages all of your work
items, then your category list is very easy ... it just has one entry in
it, and that category is mapped to the team area that is doing the
triage. And in that case, if each of your releases has its own
timeline, then you can avoid duplicating the releases in the category
list. Just map that category to the appropriate team for the
appropriate timeline (you can map the same category to different teams,
as long as each team is in a different timeline).

Cheers,
Geoff


On 12/6/2011 3:23 PM, tcherel wrote:
Thanks Geoff.

I guess I want both :-)
I want to partition both by release and by feature.
The dev/CE split is really a split by release (the release time
line/schedule for the dev team is not the same as the CE team one).
But within the dev team or the CE team, I might want to further
partition by feature.
But may be I am over-thinking it :-)

I have the impression that categories should really be components. If
I start using categories as releases, then it starts to duplicate the
notion of "planned for", I think.

Do you think that the hierarchical team feature will work? I think I
am going to try that. When new WI are created, there is anyway a
triage activity going on to decide who should take care of it so I am
not sure that the automation of the team routing through the
categories is that useful to me.

How do you map s single category to more then one team? I'm not able to do that even though the two team are on different timelines.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.