Filed Against categories: functional area vs teams
The Filed Against is a "category" and is associated with the team, but the categories could be defined as anything: they could be components or functional areas (e.g. "cli", "ui", "tool x", "parser") or they could be actual teams (e.g. "team y", "squad abc", "Dept1"). There are pros and cons to each approach but I'm wondering if there is any recommendation from folks who had experience with many teams using RTC on what typically works better (category=component or category=team/department) or perhaps there is some best practice around this?
Just to set the context: in our case, we have about 200 developers and product is broken into a lot of components/functional areas (about 30 major ones with total of about 250+ components). Team-wise, there are about 30 "chapters" (essentially one per major component) and we have RTC Team Area defined for each chapter + other Team Areas like "service", "Leads" etc. (i.e. using Team Areas to represent membership of who is on a particular team. We are not using Team Areas for separation of process/roles/etc.).
Sorry, I know this is not a real question, more like just wondering/learning what others found works best for them as far as Filed Against usage goes.
|
Accepted answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Jun 11 '17, 1:14 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER If you haven't already done so, I'd recommend reviewing the answer in https://jazz.net/forum/questions/206313/what-is-the-purpose-of-the-rtc-category.
In general, you should chose categories that makes it easiest for the work item submitter to select a category that is associated with the team that should be responsible for the work item. So the best category choices depends on both what your work item submitters know, and how your teams are structured.
If your work item submitters know what team should work on a particular work item, then just provide them with categories named after those teams (that is the simplest category system).
If the work item submitters do not always know this, then you need to add some set of categories that they are likely to understand, and that can be mapped to the right team. Note that it is usually easy to come up with categories that satisfy only one of these two criteria ... it is finding categories that satisfy both of them that is the challenge.
Also note that what you should not do is to create categories that are not required for mapping a work item to a team. In particular, I have seen users try to make the Category system 'classify' their work items in ways (or with details) that are not relevant for routing that work item to the appropriate team.
Andrei Lurie selected this answer as the correct answer
Comments Hi Geoff, thank you for the link and for sharing your thoughts on the intent of the categories. It helped me get a better idea (RTC docs don't say a whole lot about this).
I'm curious about your last paragraph, because in one instance, I think, we used categories for exactly that - to classify work into common areas or tools. Essentially we had one team developing and servicing multiple (small) tools and so we had only one team in one project area for this, and so our submitters knew which team should work on stuff. But we also wanted to classify work into several areas/tools so that we could use in planning and prioritization (certain tools were more important than others). But it does "create categories that are not required for mapping a work item to a team" this way.
So for this kind of "classification", would you recommend to create small sub-teams for each area/tool even though all teams would have same members. Or use one team and one category and then classify using a separate custom field?
Geoffrey Clemm
commented Jun 13 '17, 12:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The primary purpose of a team area for a group of users is to allow the creation of a plan for that group of users. A secondary purpose of a team area (even when a separate planning area is not required) is to create a new group for write-access control purposes. It is preferable to create a new role to define a new group for write-access control, but sometimes that would produce an excessive or unnatural set of roles, in which case a new team or project area is acceptable. You would not create a sub-team just to have a unique team to which to map a category (it is fine to have two categories mapped to the same team).
So I would recommend your second alternative: create the simplest category system that will allow work items to be automatically mapped to the correct team, and use separate custom fields for classifying the work items for purposes other than mapping the work item to the correct team.
|
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.
Comments
Please note that you can also have a mix. So you can have a category for a team (or functional domain where a team takes care of it) and then have subcategories for it that can be invisible or visible to external members. In this case you can use the subcategories as grouping in plans and the like. Another challenge can be that members don't necessarily belong to only one team. E.g. I could be in the Web UI team and the maintenance team.
Hi Ralph, thank you for your comment. We used the mixed approach you mentioned (if I understood you correctly) in our internal infrastructure team which is a small team, and our users don't know all the infrastructure components/tools, so we used Category to designate high level (e.g. RTC, Build, IDE, etc.) and then our Infra team would change it to an "invisible" sub-category to designate the actual component/tool which is useful to have for planning and other "operational" stuff like seeing which area has a lot of defects. However, seems like Geoff's reply below advises against such classification? I will comment about this under his answer.
I think the main point with categories is, that it is a very simple to use mechanism to categorize the work based on a tree structure. The work item categories should be so easy to use that any user can at least relate to something. The category can also transfer ownership to team or project areas, if needed. Note Once the initial categorization is done, the project area members can change it, if needed. The category is usually mandatory.
As is probably clear from my comments below, Ralph and I have different opinions on this point (:-). In my view, the main point with Categories is that it is the only built-in mechanism for mapping a work item to the correct team area (and that is the only built-in semantics for a Category). Using a Category for anything else should only be done if it does not interfere with that primary purpose. I do agree with Ralph that a Category is the only built-in hierarchically valued property type, and so I agree that it can be used to categorize a work item in whatever arbitrary way you want, but only if that does not interfere (or complicate) its primary function of automatically mapping the work item to the team area that should work on it. And to emphasize, this is the primary function of the Category because it is the only out-of-the-box mechanism provided by RTC to do so.