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?
Accepted answer
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.
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).
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).
Comments
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 09 '17, 2:40 a.m.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.
Andrei Lurie
Jun 12 '17, 3:50 a.m.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.
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 12 '17, 5:06 a.m.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.
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 13 '17, 12:57 a.m.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.