Question on Timeline/Sprint in RTC
Accepted answer
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.
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.
3 other answers
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.
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.
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.
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
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.
Oh, okay, thank you for the answer!