Multiple teams, single product

You can look at the way we do planning in the Jazz Project for the style that works for us. We have an iteration plan per milestone from the PMC, which contains high-level plan items, which often capture themes for the project milestone.

Component iteration plans include their implementation work items for the themes identified in the PMC plan, and are linked as children of the PMC's plan items. We use the PMC plan to review progress across components on the themes, using the "Group by folder" view in the plan editor.

Here's an example of a good PMC plan with lots of component detail: https://jazz.net/jazz/resource/itemOid/com.ibm.team.apt.IterationPlanRecord/_R6K4oNiXEdyWjYK5HLcaEg

Looking at the Planned Items page, you can see the child items from the component plans that were being done in support of the overall plan.

As we scale up to a project of this size, the backlogs are mostly local, they are no longer owned globally. Components plan a mix of work to address the PMC's themes for the iterations and existing backlog items.

Hope this is helpful.

Scott Rich
Jazz Team

bump. been watching this one waiting for an answer from the team...

As Scott pointed out looking at Jazz itself is a good start. Some
additional comments to what Scott already pointed out:

- yes, a plan must be owned by a team
- so in Jazz we have a PMC team (project management committee). I guess
if your project is with multiple teams then you will have a comparable
instance that manages the overall project
- create a team area for that team and create a category. The category
can be simply backlog if you want
- Create a plan for the release iteration for that team. Use the plan to
manage the overall backlog. Mostly this a higher level items. The
decomposition mostly takes place on a PMC iteration plan or on a
concrete iteration team plan.
- if you want a finer grain management of the backlog for an iteration,
create a plan for an iteration for the "PMC" team (that is what we do).
- depending on how you deal with stories either assign the stories to
concrete team for an iteration from the backlog plan or create an
implementation task as a child of the story and assign this one to the
team.

Hope that helps

Dirk Baeumer
Agile Planning Component

mmallo5 wrote:

We have been working with RTC for a while as a test as part of a
larger product. As a small unit we have been cool using iterations
for releases and sub iterations for monthly sprints. The release
iteration plan holds the backlog, and each month's iteration plan
contains the committed set of stories for that iteration.

I'm lost on how we do this for multiple teams in RTC though working on
a single product. Its seems each iteration plan we create is owned by
a team, so not sure how to create a release iteration plan that
contains items from all teams. I tried created a group of teams
under a larger team, but the iteration plan for the larger team says
"there are no categories associated". In our case all the
categories are assigned to the sub teams. Must we create a product
backlog for each of the sub teams and work from multiple product
backlogs?

This makes sense, what we were trying to do is to get the larger "team" to see all the sub-team tasks, but that would really end up with a lot of things to manage at the larger team level. We are going down the road and setup a Project Management Team with its own Project Management Category to hold the larger release wide-stories, then we will create implementation tasks under it that each of the sub-teams will own. We are thinking about prefixing the story with the name the sub team that owns implementation so the project management team can visually see that without needing to drill into the tasks. Thanks for this suggestion, I think its going to work out great for us.