Formal description of the link between categories, timelines and WI assignment to TAs, how can mistakes of missassigning WIs to wrong TAs be avoided.
Can someone please give answers or put here references to help me clearly understand these questions' answers:
Q1: How Categories and Timelines are associating a WI (work Item) to a team area?
Q2: How exactly the limiting of "category visibility" and "WI access" influence these assignments or their usage?
(my background is that I want to avoid a team-member to assign a WI by mistake to a wrong team and it gets lost and found when it is too late)
Q3: Is there some standard ways/scenarios of using RTC to setup a multi-team project, timelines and TA assignments to them?
(I am using a jazz installation 4.0.4 - but would appreciate any answer )
Background:
I am trying to set-up a good bases for a comparatively complex multi-team project (my ballpark is (1) Active development about 3 years :10 teams x 10 people each (2) Maintenance with maintenance horizon of 10 years)
I believe that I read a lot of info the internet search offered as well as the documentation of RTC. I even did some experiments with assignments of categories and work-items and still, my understanding becomes more and more confused.
I cannot believe that this is not explained already somewhere. Still, the fact is that I cannot find it.
->I would highly appreciate if someone can give me a formal explanation in a pseudo-code, block-diagram or any (semi-)formal way which is reliable and unambiguous.
-> I prefer to keep most of the team in a single Project Area - although this can be changed - it is not a hard requirement.
2 answers
Please see https://jazz.net/library/article/589 for an overview how this works.
A project are or team area can always only work against a single timeline. I think the sample app does a reasonably good job in showing how that would be set up.
If you do development with some teams and maintenance with others, the development teams would be at the development timeline and the maintenance teams on the maintenance timeline. They could be the same, if the rhythms are the same. I would split them for clarity however.
Name the iterations in a reasonable identifiable way.
Development
-- Release 1
---- M1 (R1)
-------- Iteration 1 (M1 R1)
-------- Iteration 2 (M1 R1)
---- M2 (R1)
-------- Iteration 1 (M2 R1)
-------- Iteration 2 (M2 R1)
and so forth.
A project are or team area can always only work against a single timeline. I think the sample app does a reasonably good job in showing how that would be set up.
If you do development with some teams and maintenance with others, the development teams would be at the development timeline and the maintenance teams on the maintenance timeline. They could be the same, if the rhythms are the same. I would split them for clarity however.
Name the iterations in a reasonable identifiable way.
Development
-- Release 1
---- M1 (R1)
-------- Iteration 1 (M1 R1)
-------- Iteration 2 (M1 R1)
---- M2 (R1)
-------- Iteration 1 (M2 R1)
-------- Iteration 2 (M2 R1)
and so forth.
Comments
Thank you for the answer. This was not exactly the question which I was asking...
I understand that my question was both too general and somewhat unclear.
Please see the comment that I added to my original question so that my question is clearer.
The team area that owns the work item is ONLY dependent on the category.
So if you choose a category, as per the description above a team area or project area is associated with it (potentially involving inheritance). The process area associated with the category selected in Filed against is owner of the work item.
The iteration is orthogonal to that. There is also some confusion about which iterations you can pick. Currently you can potentially pick more than you should be able to given the team area. There is an enhancement request to filter them out.
PS, you can have multiple categories being associated with one team area (but not the other way around). This allows for a human readable tree of categories that is independent of the organizations of your teams.
Thanks indeed, I am very very grateful for your time.
1. Can you please be more specific on "(potentially involving inheritance)" - Please elaborate a little. Specifically what is the order of inheritance -> from (1) Master Category to Child category OR (2) from "(Any)"timeline to specific timeline OR (3) both?
2. In case inheritance is in both directions can you explain priority and general way that would make sense of assignments to make maintenance easier?
3. What is "Process Area" - I know "Project Area" and "Team area" but not Process Area?
As you stated that
" you can have multiple categories being associated with one team area (but not the other way around)"
4. does it mean that different TAs can be assigned for different Timelines only if these TAs are "children" ( hierarchically included ) in the original TA assigned in the "(any)" timeline?
4a. if yes, is this also true for the "root category" - I guess that we can still assign a different root category for a timeline - to completely override the other assignments, right?
Please have a look at https://jazz.net/library/article/589 especially the image
As you can see there is no direct relationship between the category and the timeline, nor the iteration a work item is filed against. So your second part of question 1 in your comment shows your confusion. Forget timelines if you talk about categories for the moment. The selection of the timeline in the category editor is only to make it easier to find the process area based on filtering their associated timelines. Process area is a general term for team area or project area I use, because they share a lot of things, a project area is like a team area in most properties. The difference is that a project area can not be contained in other process areas. Process area is actually something that exists in the API.
You only associate a category and a process area. At this point, timelines are not relevant at all.
You can associate a category to any process area you want. If a category is created as subcategory of another one, it initially inherits the association to the process area from its parent. But you can override that. Wireless inherits its association from Mobile, but Bongo Drums is overwritten. Please note, inheritance only reflects the process area association.
An given process area can only follow exactly one timeline. By default a team area is set to follow the project timeline. The root team areas directly underneath a project area can have a different timeline associated. Any team area underneath such a root team area shares its timeline.
So if you have a development timeline, you would typically have the project area follow that timeline. Team areas within would follow it too - assuming there is more development than maintenance.
If you want a team area for maintenance, you would create a new root team area that works against the maintenance timeline. If you want sub teams in maintenance, you create them within.
Edit: See the image
Maintenance Team runs on its own timeline, different from the one the project area uses. The sub team Ble can only run on the timeline of the maintenance team. Business Recovery Matters and the other team areas run on the Project Area Timeline and their sub team areas run on the ones chosen in the root team area as well.
With respect to category-team area-timeline, the UI allows you to choose a category for a work item. Once you have chosen that, you probably should only be able to choose an iteration from the timeline the associated team area works against. However, the UI allows you to pick other iterations, which does not make a lot of sense from a planning perspective. There is an enhancement request.
As you can see there is no direct relationship between the category and the timeline, nor the iteration a work item is filed against. So your second part of question 1 in your comment shows your confusion. Forget timelines if you talk about categories for the moment. The selection of the timeline in the category editor is only to make it easier to find the process area based on filtering their associated timelines. Process area is a general term for team area or project area I use, because they share a lot of things, a project area is like a team area in most properties. The difference is that a project area can not be contained in other process areas. Process area is actually something that exists in the API.
You only associate a category and a process area. At this point, timelines are not relevant at all.
You can associate a category to any process area you want. If a category is created as subcategory of another one, it initially inherits the association to the process area from its parent. But you can override that. Wireless inherits its association from Mobile, but Bongo Drums is overwritten. Please note, inheritance only reflects the process area association.
An given process area can only follow exactly one timeline. By default a team area is set to follow the project timeline. The root team areas directly underneath a project area can have a different timeline associated. Any team area underneath such a root team area shares its timeline.
So if you have a development timeline, you would typically have the project area follow that timeline. Team areas within would follow it too - assuming there is more development than maintenance.
If you want a team area for maintenance, you would create a new root team area that works against the maintenance timeline. If you want sub teams in maintenance, you create them within.
Edit: See the image
Maintenance Team runs on its own timeline, different from the one the project area uses. The sub team Ble can only run on the timeline of the maintenance team. Business Recovery Matters and the other team areas run on the Project Area Timeline and their sub team areas run on the ones chosen in the root team area as well.
With respect to category-team area-timeline, the UI allows you to choose a category for a work item. Once you have chosen that, you probably should only be able to choose an iteration from the timeline the associated team area works against. However, the UI allows you to pick other iterations, which does not make a lot of sense from a planning perspective. There is an enhancement request.
Comments
Leonid Guelsinov
Oct 07 '14, 11:47 a.m.I am afraid that my answer is not clear after seeing the first answer so I have made a simple refinement: