Different timelines and delivery approval
Hello,
we have a customer (RTC 3.0.1) which is facing the following problem:
We have different timelines for stable releases (that require approval) and next development releases (which do not require approval). The way RTC handle up this requires different team areas for both timelines (which would still be ok). But a further consequence is that different team areas require different sets of categories. In other words: a defect to a stable release needs different categories ("Filed against" field) than a defect to a next dev release. This approach is not acceptable as it leads to confusion. It would mean that if we move a release to approval a complete set of categories applies and the "Filed against" fields need to be updated. Also the visibility in the plans is restricted.
In an alternative setup in one timeline it seems that the approval setup of the current iteration overwrites all approval settings of the other iteration. Therefore, it seems impossible to have both streams with and without approval in one timeline.
Any thought, solutions on this?
Thank you
2 answers
Hi Zica,
In my project's self-hosting we use the separate timeline approach you described first, except we use the same categories for defects filed against stable and next dev iterations. In order to control permissions/approvals separately we do have separate team areas, one for stable with a stable stream associated with it, and one for next dev with a next dev stream associated with it. But for defects planned for both timelines we use the same categories (the ones associated with the next dev teams in our case). Maybe a similar setup would work for your team?
Hope that helps,
Parker
Process team | Jazz Foudation
In my project's self-hosting we use the separate timeline approach you described first, except we use the same categories for defects filed against stable and next dev iterations. In order to control permissions/approvals separately we do have separate team areas, one for stable with a stable stream associated with it, and one for next dev with a next dev stream associated with it. But for defects planned for both timelines we use the same categories (the ones associated with the next dev teams in our case). Maybe a similar setup would work for your team?
Hope that helps,
Parker
Process team | Jazz Foudation
Comments
Thank you Parker for your answer.
I agreed, a comprehensive document with best practice for different mappings/configuration would be a benefit for many RTC users facing this problem.
Gregor, both mappings are possible:
-You can map the same category to different teams ( https://jazz.net/forum/questions/68484/team-areas-categories-and-wis-again ). Maybe this article will also give you a hint about a possible config.
- It is possible to have multiple categories assigned to a team area (https://jazz.net/library/article/589/)
You can associate multiple teams with a single category when you have multiple timelines. A category can have a different team assigned per timeline.
I agreed, a comprehensive document with best practice for different mappings/configuration would be a benefit for many RTC users facing this problem.
Gregor, both mappings are possible:
-You can map the same category to different teams ( https://jazz.net/forum/questions/68484/team-areas-categories-and-wis-again ). Maybe this article will also give you a hint about a possible config.
- It is possible to have multiple categories assigned to a team area (https://jazz.net/library/article/589/)
You can associate multiple teams with a single category when you have multiple timelines. A category can have a different team assigned per timeline.
Comments
Comments
G Moehler
Sep 14 '12, 9:22 a.m.