Problems with timelines impacting ability to use plans and My Work view
We use RTC 3.0.1.3 but to my knowledge this hasn't changed in any later version of RTC.
We have on project area that his 4 direct child team areas. Then all other team areas children of those 4. The problem I have is that with this structure we can't use the My Work view effectively and also allow teams to use plans for different iterations.
Different teams may be working on a different deliverable, and therefore, a different release or iteration schedule. Since these are going on parallel, I have to create them as multiple timelines in the project area because you can only set one iteration in the timeline as current so that it properly displays in the My Work view. This, however, impacts our ability to use plans because many of the team areas can only inherit the timeline that is set by the high level team areas.
I can change our multiple timelines to merge into one timeline set for the project and all team areas with nested releases, iterations, and sub-iterations that will allow teams to create the needed but plans. However, this then breaks the My Work view because we can't select multiple iterations in this one timeline to be considered the current iteration (as they are in reality). This impacts those who rely on the My Work view.
I don't see a way to fix this in RTC. Am I missing something? The only solution I see is to then flatten the team area structure which then has other impacts on inherited permissions, etc.
It seems like it would be better to let all team areas select their own timelines regardless of where they reside in the hierachy of teams but perhaps I don't understand the reason for that restriction. Is there a way to lift this restriction in custom code?
We have on project area that his 4 direct child team areas. Then all other team areas children of those 4. The problem I have is that with this structure we can't use the My Work view effectively and also allow teams to use plans for different iterations.
Different teams may be working on a different deliverable, and therefore, a different release or iteration schedule. Since these are going on parallel, I have to create them as multiple timelines in the project area because you can only set one iteration in the timeline as current so that it properly displays in the My Work view. This, however, impacts our ability to use plans because many of the team areas can only inherit the timeline that is set by the high level team areas.
I can change our multiple timelines to merge into one timeline set for the project and all team areas with nested releases, iterations, and sub-iterations that will allow teams to create the needed but plans. However, this then breaks the My Work view because we can't select multiple iterations in this one timeline to be considered the current iteration (as they are in reality). This impacts those who rely on the My Work view.
I don't see a way to fix this in RTC. Am I missing something? The only solution I see is to then flatten the team area structure which then has other impacts on inherited permissions, etc.
It seems like it would be better to let all team areas select their own timelines regardless of where they reside in the hierachy of teams but perhaps I don't understand the reason for that restriction. Is there a way to lift this restriction in custom code?
One answer
BTW, your general assessment is spot-on. If you have independent teams working on different deliverables and perhaps different sprint lengths, multiple timelines is the say to go. And sub-teams inherit the team's timeline (that's how I think of it -- you can have Teams that have sub-teams, meaning they are subordinate to that Team and its general configuration and must work on its timeline).
[I think of] A Plan as a fancy query presentation: you specify an owner and iteration and it pulls the matching work items. So if something is Filed Against Work for Team A and Planned for Product A Sprint 1, it will show up on a plan whose owner is Product Team A (assuming proper work item category configuration) and iteration is Product A Sprint 1. There is no way for a normal plan to pull work for more than one owner nor more than one iteration. However, plans can roll up, so the plan described here can gather work from all of the subteams for Product Team A.
I can't imagine why subteams of Product Team A would need to be on different timelines, since they are working on the same product .
Comments
Millard, thanks for the response.
I can't imagine why subteams of Product Team A would need to be on different timelines, since they are working on the same product .I think this hits on our root problem. I believe our team areas probably aren't setup correctly. We initially setup our product with one Development team which was used to manage who had source stream visibility and access by controlling its members and roles. Then all development teams were children of this team area regardless of the project they were working on.
So while we could set the timeline for the Development team, all child teams inherited this setting even though some subset of team areas really were working on side projects with different timelines.
It sounds like we should re-structure our teams so our high level teams are related to specific releases and then have child scrums and sub scrums under that. We're going to a more agile approach so we're re-evaluating our configuration now.
I rearranged this to show an answer. I am aware there are reasons for comments, but I think there is an agreement that it would make sense to restructure to solve the issue and I think Millards comment should really show as an answer.
Comments
Millard Ellingsworth
FORUM ADMINISTRATOR / JAZZ DEVELOPER Jun 20 '13, 9:37 p.m.> we can't use the My Work view effectively