It's all about the answers!

Ask a question

Problems with timelines impacting ability to use plans and My Work view

Phillip Piper (15812524) | asked May 30 '13, 12:53 p.m.
We use RTC 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?

Millard Ellingsworth commented Jun 20 '13, 9:37 p.m.

> we can't use the My Work view effectively 

I'd like to help, but I need a better understanding of what that means to you. I created a project, added 3 timelines to it along with 3 teams and 3 work item categories and established the various relationships. I set Sprint 1 as current on all timelines. I put myself in each team and assigned myself a task for each team/timeline. My MyWork view looks like this:

It gathered my work for each team I'm associated with for the current iteration under Current Work and I can see upcoming work organized by Team area and Iteration.

I realize my setup isn't quite as complex as yours but I'm reasonably certain that if I added sub-teams and assigned myself work, it would show up. What am I missing about what you'd like to see?

One answer

permanent link
Millard Ellingsworth (2.5k12431) | answered Jun 20 '13, 9:49 p.m.
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 .

Phillip Piper commented Jun 21 '13, 12:33 a.m. | edited Jun 21 '13, 3:15 a.m.

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.

Ralph Schoon commented Jun 21 '13, 3:18 a.m.

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.

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.