Question on organizing teams and plans for larger projects
I have a project where several teams contribute. Assume I have Team1 and Team2.
I defined a team area for both, Team1 and Team2. Because sprint plans are always associated to teams, I will create 2 sprint plans for every subsequent iteration. I will also create two team backlogs that contain all items per team for the release. To be able to assign work items to team backlogs, I need to define at least one work item category per team and associate the category with the team. Please correct me if I am wrong so far. On top of the above, I want to have one overall product backlog. Therefore I create a plan of type Product Backlog because: (a) I want to see all items for all teams. (b) I want to do the initial release planning without bothering about team assignments, i.e. all new epics and stories go to the product backlog first. Now I have the following question: In the current setup, I could associate the Product Backlog plan to the project area. Then, I create an additional work item category that is not associated with a team area. This is a feasible solution, however, is it also a recommended solution? Another option would be to define Team1 and Team2 as subteams of a project team (the project team would be for structuring only, i.e. would not have members). In this case, I could associate the Product Backlog with the project team and the additional work item category would be associated with the project team. This, too, is a feasible solution. Question to the agile planning team: Which one would you consider to be the preferable solution? Thank you very much for your advice - Thomas |
6 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 18 '09, 10:51 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Everything you wrote sounds fine to me.
I always go with the minimal machinery that meets my needs, so I'd go with option A, i.e. create a new category that is assigned to no team, which effectively assigns it to the project area (this avoids the creation of the "dummy team"). Cheers, Geoff starz wrote: I have a project where several teams contribute. Assume I have Team1 |
|
Thanks, Geoff, makes sense.
What I am wondering is if there is a difference in reporting; will the release/product burndown report look the same for both options? Also, is there a difference in permission handling? I am a little confused... could it be that in case (a) members of the project have access to the product backlog but in case (b) - the one with the dummy team - they don't? |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 18 '09, 8:49 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I don't think that this will affect the release/product burndown report,
but I'll defer to the planning/reporting teams on that question. Read access control is just based on the project area ... it doesn't matter what team area you belong to. Write access control is based on permissions. I don't see any benefit in having a dummy team in this case ... you can just define those permissions in the project area itself. But I may be missing something, so consider this just an "informed opinion" (:-). Cheers, Geoff starz wrote: Thanks, Geoff, makes sense. |
Hi
A comment on the "Dummy Team". There may be occasions when you may want this "Dummy Team Are", or Development Line Team Area which is the name I prefer. If you use the Agile practise of "Two-Level Planning" you may choose to have the Team resposible for the release activites in the same RTC Project Area as the Team resposible fo implementing new requirements. In this set-up you may want to separate the overal plans for the development line and Release activites. Then the "Dummy Team Area" will become usefully. /Torbitz |
|
@Geoff and @Torbiz (and others): Can you please help me again?
My intention is to find a recommendation that fits for all teams without many if's and but's. While in general such a simplification is certainly not always possible ;-) in the current case I could imagine that we may recommend the approach with the product backlog associated to a (dummy) team area. This might even be simpler (remember that when creating a plan, RTC suggests associating it to a team area by default) and seems easier to extend.... but I really would like to get your opinions on that before I go ahead and recommend this solution. Thanks again - Thomas |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 19 '09, 8:32 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Team Concert makes it easy for you to add new team areas anywhere you
want into an existing team hierarchy, so I still prefer to start with the "fewest number of team areas that you need" approach. But either way is really fine, so you should do whatever you prefer. BTW, where does RTC suggests associating the plan with a team area by default? Cheers, Geoff starz wrote: @Geoff and @Torbiz (and others): Can you please help me again? |
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.