Different timelines and delivery approval

Zica Valsan (101●2●46●45) | asked Sep 14 '12, 6:47 a.m.

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

Comments

G Moehler commented Sep 14 '12, 9:22 a.m.

One addition from my side: for the alternative setup (modelling approval within parallel iterations in one timeline) we have opened a defect (https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=230951).

A further alternative approach would be to have one timeline for each release (instead of just two), but leads to the same problem: It requires different sets of work item categories for each release (which would contain the same single categories internally). When opening defects to different releases the user again would have to choose from different sets of work item categories - and moving a defect from one release to the other would require a change in the categories chosen in the "Filed against" field as well.

2 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Parker Dunton (406●4) | answered Sep 14 '12, 12:53 p.m.
JAZZ DEVELOPER

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

Comments

Daniel Stefan Haischt commented Sep 14 '12, 6:09 p.m.

No matter what solution is the most appropriate one, I am strongly inclined to think that an article on jazz.net covering all of the different, possible solutions here would be the most appropriate way to shed some light and thus help understanding people how to actually setup their RTC infrastructure in the long run. It is just almost impossible to get this right in the first place as it looks like from the above post.

G Moehler commented Sep 16 '12, 3:58 p.m.

Thanks for the answer. So you are saying that you also use one timeline for stable releases and one timeline for next dev releases - each with one team behind it. And when someone opens a defect against one of the stable releases it would be opened using the categories associated with the next dev team. Correct? I can understand that this works as a work-around. But strictly speaking the categories used in the defect are associated with the wrong team. And, it would not work for project planning: In plans you need to use categories for the correct team, otherwise the items do not show up. Since people usually do planning for the next development it would work for future plans - but as soon as you have moved the stream to the stable (maintenance) team - you would no longer be able to look at the plan, since all categories used for work items are now associated with the next dev team. A big drawback IMHO. Another drawback is that you need to maintain 2 team areas even though they are (in our case) exactly the same. In a nutshell: I understand that this can be used as work around - but is there no solution that models our situation precisely? Gregor

G Moehler commented Sep 16 '12, 3:59 p.m.

One addition: In my mind it should be possible to associate the work item categories with more than one team. Then the setup would be able to reflect the situation correctly.

permanent link

Zica Valsan (101●2●46●45) | answered Sep 17 '12, 4:12 a.m.

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.

Comments

Parker Dunton commented Sep 17 '12, 1:08 p.m.

JAZZ DEVELOPER

Great point Zica. This is what we do in our self-hosting, we associate our next dev team with their category in the next dev timeline, and we associate the stable team with the same category in the stable timeline

G Moehler commented Sep 18 '12, 6:15 p.m.

Great - thanks for this hint, Zica, that looks very close to a comfortable solution - one team for stable and one time for next development, but only one set of categories. A bit more down on the wishlist is that all this would also work with just one team defined. But i guess that does not work since it is just the different team areas (stable vs. next) that makes the link between the different timelines (and different approval behaviour) on the one side and the streams on the other side. Correct? Or is there any solution with just one team area? Going further to a solution with one timeline per release (and again one stream per release). Is this recommended at all? If it is, would you again need one team per timeline or is it "somehow" possible to work with 2 teams (stable vs next). I would not see how this could work since you can only enter one timeline per team. Or am i missing something?

Parker Dunton commented Sep 18 '12, 6:59 p.m.

JAZZ DEVELOPER

That is correct, as of now, a team area may only be associated with a single timeline.

It's all about the answers!

Related questions

Different timelines and delivery approval

2 answers

Your answer