Planning with multiple teams
Hi,
We have a RTC project that has two subprojects inside. Each of the two projects is assign to a different team. We have also different releases and iterations for this project. Let's suppose the project name is PRJ and the two teams are TM1 and TM2. We have release 1.0 (with iteration 1.0.1 and 1.0.2) 2.0 (with iterations 2.0.1 and 2.0.2). I have created following team areas for each of the releases: PRJ_1.0, TM1_1.0, TM2_1.0 (for release 1.0) PRJ_2.0, TM1_2.0, TM2_2.0 (for release 2.0) I have also create streams for both releases: PRJ_1.0_Stream for the full release (owned by PRJ_1.0 team) TM1_1.0_Stream for the release of the TM! functionality (owned by TM1_1.0 team) TM2_1.0_Stream for the release of the TM2 functionality (owned by TM2_1.0 team) etc... The last two streams are flowing into the PRJ_1.0_Stream This will insure the isolation that we need between the two teams. I'm now trying to implement planning for everything. After creating the Release Backlog (owned by PRJ_1.0 team) I'm trying to create an iteration logs for each of the teams (one owned by TM1_1.0 and another owned by TM2_1.0). However I cannot link the release backlog with the two iteration logs because they are owned by two different teams. The two teams TM1_1.0 and TM2_2.0 are child teams for PRJ_1.0. If I change the owner of the iteration plan from TM1_1.0 to PRJ_1.0 then I cannot see the members of the TM1_1.0 under the plan, but I can link the two plans together. What I want to achieve is that users from PRJ_1.0 team will populate the release backlog and move then tasks into the proper iteration log and the people from the two subteams TM1_1.0 and TM2_1.0 can access the assigned tasks in the iteration logs. What am I doing wrong? Is this even possible? Thank you. Regards, Radu B. |
6 answers
Ralph Schoon (63.4k●3●36●46)
| answered Jan 11 '11, 4:25 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi,
please help us to better understand what you want to do. For example there are no subprojects in RTC. See http://jazz.net/library/article/383 as examples on how planning works in RTC. There are other articles about agile in the library as well, such as http://jazz.net/library/article/381. Let us understand what you intent to do. Lets start here so I assume you want to use a RTC project area PRJ with sub team TM1 and TM2 to develop something e.g. PR. PR is supposed to be developed in two releases R1.0 and R2.0 each split in iterations. Is that about correct? Why 2 teams? Organizational or one different team for each release? Below you create 4 Team areas - I don't see the reason why? Since if it is just one product and R2 would be based on R1 in the case I described one would setup a timeline with consecutive releases. TL R1.0 --I1 (R1) --I2 (R1) R2.0 --I1 (R2) --I2 (R2) One or more teams would be able to work against this timeline, however only one iteration would be the current one for all teams working on this timeline. This setup reflects where one develops R1 and then later develops R2 based on that. Please note, a team could work on elaboration for R2 on a separate stream while the other team still develops R1. Teams on the same timeline can share plans such as the backlog. The plans don't have to be linked. What the plans show would only be determined by the parameters you provide when configuring them and on the team and timeline structure. When creating plans please be aware that plans can be on project area level as well as on team level. If you want multiple teams to share a plan, you have to configure it accordingly. You would use the different plan types. Different plan modes/views also filter for different aspects. Your Team hierarchy could be more elaborate where you have TM1 and TM2 under the same root team TM1. You could also set up TL1 R1.0 --I1 (R1) --I2 (R1) TL2 R2.0 --I1 (R2) --I2 (R2) where teams work on completely separate time lines. In this case both work completely independent. The plans always only cover one time line. So you have a separate plan hierarchy for both timelines, including a separate backlog for each iteration. Hi, |
|
Hi Ralph,
Thank you for your comprehensive answer. I will try to explain my setup a bit better below. We have a project that develops a product that has two different subcomponents. Each subcomponent is developed by a different team and there is a need for these teams to work in isolation. The project however, will have a common release schedule. This is a bit like the RTC project on jazz.net. There is a common release (3.0.1) and inside a release you have a release of individual components( SCM, Build, ClearCase Connector). So the project is PR and the two subcomponents are SC1 and SC2. We have two timelines (Development and Maintenance) with multiple releases and iterations: Development --2.0 --2.0.1 --2.0.2 --3.0 --3.0.1 --3.0.2 Backlog Maintenance --1.0 --1.0.1 --1.0.2 The development can happen in different releases in the same time but only one iteration is current (development can start for the next release before the current iteration has finished). After delivering a release this should move to maintenance timeline. The work for release 2.0 is split between the two teams SC1 and SC2. Each of the teams should have it's own iteration plan and there should be a common release plan. There should be a PR team that supervises the work on project level. The release plan should be populated by the PR team with tasks for both SC1 team and SC2 team. The same team should then assign different tasks to the iteration plans that are team specific (SC1_2.0.1 and SC2_2.0.1). At the end of the release the unfinished tasks will be moved to Backlog plan (product backlog) and from there into the next release plan. These is another job for the PR team. The maintenance work is handled by two different teams SC1_Maint and SC2_Maint. There is no PR team as such. I'm using the project level for this. I'm adding this users to the project, thus giving them full access for all the plans. The Product Backlog and Release Plans are all owned by the project (plan at project level). For each iteration I have two plans, one for each team SC1 and SC2. These plans are owned by the individual teams. In the Release backlog I can see a line for each iteration but when I click on one of them I get the message that "The team PR has no plan for iteration ". However I have an Iteration plan for one of the iterations in this release. I want to see all the tasks in the release plan broken by iterations and I want to allow the two teams to update the tasks in their individual iteration plan. Hope this time I was more concise in my explanations. Thanks, Radu B. |
|
Ralph Schoon (63.4k●3●36●46)
| answered Jan 12 '11, 6:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Radu,
thanks for the clarification. My recommendation would be to try the following. For each time line set up the following structure PR Dev ---- 1.0 -------I1 (1.0) -------I2 (1.0) ... ---- 2.0 -------I1 (2.0) -------I2 (2.0) ... ----backlog (backlog iteration) The team structure: not sure, I would have to try if 1. or 2. is better 2. allows to see the work planning by team and I'd probably go with that because it is how I typically structure. Also the process customization for 2. would allow to make good defaults on Team level and additional on sub team level. This seems to be how the Jazz team organizes itself. 1. PR project area ---- Team 1 ---- Team 2 2. PR project area -- PR Team ----- Team 1 ----- Team 2 The two/three teams are assigned to the time line above. In 2. Team 1 and Team 2 inherit the timeline from PR Team. In 2. you could put the managers into PR Team with some sensible chosen Role. I typically use this structure. On Project level I usually only maintain roles that have to have access to all data of all sub teams. With 2. you can now create a project release plan with iteration PR Dev that shows all data for all releases. You can also create one with target iteration 1.0, 2.0, .... which would show all iterations/teams etc underneath. For each iteration you can have an iteration plan that shows only data for the iteration etc. You can also create backlog plans etc. the way I understand you want it. Just play with the plan types and the owning Team/project as well as the target iteration it is configured for. Similar to the Maintenance Timeline "PR Maint" you could set up maintenance Team(s). The SCM part is really natural, have a component for each component and a stream hierarchy that allows to work i n parallel and finally do integration like Team 1 Component 1 development Stream, Team2 Component 2 development stream. (The streams could contain both components but would focus on evolving the one assigned to the team). Then at lease Release x.0 Integration stream. If needed create more. Streams for maintenance would be similar, maybe not split into the components if not needed. I hope this helps a bit. Ralph Hi Ralph, |
Hi Radu, Hi Ralph, thanks for the explanation. I'm afraid that it is so complicated. I wish one project area would be enough so that teams can share a common backlog. Frank. |
|
Ralph Schoon (63.4k●3●36●46)
| answered Jul 05 '11, 3:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Frank, plans today can have only a backlog iteration on the timeline belonging to the plan. If you want to manage one backlog for several teams with separate timelines, you could investigate using a query that collects from several backlogs. Alternatively you could use the query to assign all backlog items to a backlog team/timeline or something similar. This could serve as a common backlog where all teams can pick up items. |
|
Ralph Schoon (63.4k●3●36●46)
| answered Jul 05 '11, 3:28 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Hi Radu, Hi Ralph, thanks for the explanation. I'm afraid that it is so complicated. I wish one project area would be enough so that teams can share a common backlog. Frank. The answer above does not imply two project areas. It implies several timelines as well as several team areas within one project area. |
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.