multiple Scrums (Teams) inside RTC : need best practices
Hi All,
I have a question regarding the integration of several Scrums in RTC.
Today, we use RTC with only one Scrum (one team) with releases and iterations. It does perfectly work.
Now, 2 other teams want to use RTC.
My question is the following : what is the best way to integrate these two new teams in RTC:
1- Either should we create 2 other independant RTC projects, one for each new Team?
2- Or should we keep only one RTC project and create several timelines and several teams inside it?
In fact, we need best practices regarding the multi-team implementation.
Using only one project is perhaps constraining : for instance, in such a case, each team could not create its own welcome dashboard and can be disturb by information of the other teams
Creating several projects, one per team, has perhaps some disadvantages (like no way to create dependencies between teams). Perhaps administration work increases with the number of RTC projects.
As a consequence, could you give to us best practices regarding this topic?
Thanks a lot for your expertise,
Mikal Donini,
Toulouse, France.
I have a question regarding the integration of several Scrums in RTC.
Today, we use RTC with only one Scrum (one team) with releases and iterations. It does perfectly work.
Now, 2 other teams want to use RTC.
My question is the following : what is the best way to integrate these two new teams in RTC:
1- Either should we create 2 other independant RTC projects, one for each new Team?
2- Or should we keep only one RTC project and create several timelines and several teams inside it?
In fact, we need best practices regarding the multi-team implementation.
Using only one project is perhaps constraining : for instance, in such a case, each team could not create its own welcome dashboard and can be disturb by information of the other teams
Creating several projects, one per team, has perhaps some disadvantages (like no way to create dependencies between teams). Perhaps administration work increases with the number of RTC projects.
As a consequence, could you give to us best practices regarding this topic?
Thanks a lot for your expertise,
Mikal Donini,
Toulouse, France.
One answer
Hi Mika,
it would reduce administrative overhead if you keep the teams in one project area. This is only possible if the teams want to run the same process, including work item customization however.
Another aspect is visibility of data. you can restrict access for different project areas. Limiting access to work items to teams within one project area is possible but has cumbersome consequences.
The teams would also have the same work item category structure if they share a project area.
So bottom line, if you use a standard process in all teams and you don't want to be able to customize them independently, and all the other things above are OK with working in one project area, use one project area.
If the teams are working closely together I would go for a project area also, because they might want to share work items.
If there are any reasons against it, use different project areas.
it would reduce administrative overhead if you keep the teams in one project area. This is only possible if the teams want to run the same process, including work item customization however.
Another aspect is visibility of data. you can restrict access for different project areas. Limiting access to work items to teams within one project area is possible but has cumbersome consequences.
The teams would also have the same work item category structure if they share a project area.
So bottom line, if you use a standard process in all teams and you don't want to be able to customize them independently, and all the other things above are OK with working in one project area, use one project area.
If the teams are working closely together I would go for a project area also, because they might want to share work items.
If there are any reasons against it, use different project areas.