It's all about the answers!

Ask a question

Question on Timeline/Sprint in RTC


1
1
T M (8878188143) | asked Jul 29 '12, 4:42 p.m.

I have a development team trying to follow Scrum in RTC and has work items targeted for releases 10.8 and 10.9 in the same sprint in the same timeline. I tell them 10.8 and 10.9 should be in different timelines with its own sprint. Any comment? 

Thanks!

Accepted answer


permanent link
Guido Schneider (3.4k1491115) | answered Jul 30 '12, 2:40 p.m.
There is no clear concept for this in RTC yet. You have several possibilities. Each has advantages and disadvantages.

a) Work in multiple timelines
    + Each release has it's own sprints
    + each release has it's wn current iteration
    + reporting per release is given
    - a team per timeline
    - separate sprint plans
    - no possibility to see all work release independant
b) Work in one timeline with multiple releases in parallel
    + Each release has it's own sprints
    + reporting per release is given
    + a team can work in both releases
    - only one release can have the current iteration
    - separate sprint plans
    - not exactly clear what happens in the system when iterations have start/end date in parallel. Sepcially in some reports.
c) Work in one timeline with release independant common sprints
    + a team has one sprint plan
    + clear current iteration
    - reporting per release is difficult
d) An extension of a) with a timeline per parallel release and one common timeline for the team sprints.
    + clear independant multiproject management and reporting
    + project independant sprint teams, doing just their work
    - complex setup and usage
    - outplaced item management in v.3.0.1 not supporting to see children in other timelines
   
In scenario c) you could separate the releases with help of categories. And in plans you can add planviews grouped by categories, so you get a "Release" view.

We decided to go to scenario b) and live with multiple sprint plans per team.
The current iteration is set to the next release. If your number of workitems is not so much (<2000 items) you can also create a plan over all so you have both releases in one plan. But this doesn't scale much.

What we would need is some sort of a "Delivery Target", which can be used as grouping in a plan and also as server based filter, like owner and iteration. The current "Release" is not useable for this because it is used in the build system and as "Found in". This is much later in the process.

see also my request (I should rewrite it a bit, I think): https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=208969

maybe you can comment on the WI.

Ralph Schoon selected this answer as the correct answer

Comments
Ralph Schoon commented Apr 18 '16, 10:02 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I agree that there are features to be desired. Several. To make iterations and releases more independent, to be able to see exceeded deadlines based on some fixed due or other date. I have seen several valid requests. I think there are also enhancement requests already.

3 other answers



permanent link
Ralph Schoon (63.6k33646) | answered Jul 30 '12, 4:05 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If the team works on two sprints in parallel the planning component would assume two timelines which would imply two team areas.

If you want to keep one team area and one timeline and you have some people working on items for the next sprint you could create separate plans for each sprint. If you want to see more than one sprint you can setup the timeline this way:

timeline.
   Release_Iteration
      sprint 1
      sprint 2

You can use the release_Iteration as iteration for a plan and that would allow you to group by sprints in the plan and see all sprints.

Comments
Guido Schneider commented Jul 30 '12, 2:12 p.m.

This is the basic setup, which does not solve the issue, that a team can not work in one sprint for different releases or better called product deliveries. RTC has a big hole in this area. Specially for system projects.


permanent link
sam detweiler (12.5k6195201) | answered Jul 29 '12, 5:30 p.m.
is it the same team? its all just work, so no need to make separate content.  the plan view should be the work for the sprint, regardless of the deliverable label.

Comments
T M commented Jul 29 '12, 5:40 p.m. | edited Jul 30 '12, 9:23 a.m.

Yes, same team. The problem is how will I get the status of just 10.8 if the sprint has both 10.8 and 10.9? The plan shows up both 10.8 and 10.9.


permanent link
Patrick Fink (111) | answered Apr 15 '16, 8:49 a.m.
edited Apr 15 '16, 8:58 a.m.
 Did someone try to configure option d) proposed by Guido Schneider? I would like to give it a try but I didn't manage to assign the same work items to iterations of two different timelines and view them within two different plans (one for sprint's, one for releases)...

It's possible to add additional attributes with type iteration, but the plans do not take these custom attributes into consideration...

Comments
Ralph Schoon commented Apr 18 '16, 4:09 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

D) does still imply that a work item can only be filed against one timeline. The planning component is basically designed that way. You could add a work item attribute of type iteration, but the planning component would not care for the custom attribute. So you will have separate work items for the release timelines and for the common development timeline. You would have to link between the items and as mentioned by Guido, the plan for one timeline/iteration/team will not always show the referenced items that are shown on a different plan. These are called outplaced items and in older RTC versions only certain relationships where shown.


Patrick Fink commented Apr 18 '16, 6:58 a.m.

Oh, okay, thank you for the answer!

Your answer


Register or to post 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.