Welcome to the Jazz Community Forum
RTC Timeline
We would like to use RTC for a project with multiple scrum teams and parallel development for multiple releases. All scrum teams are shared between the releases. What would the best practice timeline setup here ?
What is the downside of having only one current iteration selectable in RTC when multiple releases are under a single timeline ?
Thanks !
What is the downside of having only one current iteration selectable in RTC when multiple releases are under a single timeline ?
Thanks !
Accepted answer
Hi Anuradha,
the question is, are all the teams supposed to be running the same rhythm and release/milestone iteration structure at the same time? If that is the case, you can run on just one timeline.
If the teams are working on different products and milestones and the start and end dates of the releases and milestones are not the same, you would create several timelines, one for each temporal structure. With just one timeline you would not be able to express different rhythms. For example, if you have teams that run weekly sprints and others want to run bi weekly sprints. Or if some teams want to have a milestone per 4 weeks and others rather one per 6 weeks. Separate timelines would give you that flexibility.
The advantage of having just one timeline would be less administrative overhead.
I would be not that concerned at this point. You can start with one timeline and if you see needs changing over time, you can add timelines and move teams to them.
the question is, are all the teams supposed to be running the same rhythm and release/milestone iteration structure at the same time? If that is the case, you can run on just one timeline.
If the teams are working on different products and milestones and the start and end dates of the releases and milestones are not the same, you would create several timelines, one for each temporal structure. With just one timeline you would not be able to express different rhythms. For example, if you have teams that run weekly sprints and others want to run bi weekly sprints. Or if some teams want to have a milestone per 4 weeks and others rather one per 6 weeks. Separate timelines would give you that flexibility.
The advantage of having just one timeline would be less administrative overhead.
I would be not that concerned at this point. You can start with one timeline and if you see needs changing over time, you can add timelines and move teams to them.
Comments
Also, I would recommend starting with one timeline, and only introduce an additional timeline if there are important reasons do to so. Having each team work on a similar rhythm usually helps simplify communication and synchronization between teams.
Hi Ralph,
That's what we were hoping to do. We've experimented with multiple timelines and assigning different timelines to different teams, but we were shocked to discover that even if you are a member of a team, you can see all timelines/iterations in the Planned For list. Not what we expected. So, it appears that multiple timelines are extremely limited. We are using 4.0.3, so I sincerely hope that it works as you would expect it to in later versions.
Why should someone in one team not be able to see the timeline of another team? That does not make sense to me.
There is a use case, where in the drop down list it makes sense to only show iterations of the timeline related to the team the work item is filed against. This is being considered. However, it is also not trivial. What to show if it is not filed against a team and so forth?
Thanks Ralph, I guess we are thinking differently about it.
Actually, it makes no sense whatsoever to us here why it works they way that it does? Even the different rhythms mentioned above can me managed without timelines. So, in the current implementation we can see very little use (if any) with the way it works.
Which is a shame, I think RTC would have been far more powerful if it worked the other way. Still, I do take the points you raise.