Hello,

we are using RTC since a few weeks, and I would like to have an advice on how to manage multiple teams in RTC.

I have a Scrum team of 20 peoples for a Sprint of one month. I would like to split the team in 2, and have 2 team of 10 for a Sprint-X-DEV1, and Sprint-X-DEV2.

Rapidly, I need to extends the model for 6 concurrent Scrum Teams working in the same timeline (1 month).

Do I create a Plan Sprint-X sprint (to have a Sprint backlog), with 2 under plan sprints? Or do I need to manage that with the Team Allocation?

thanks for any response!

Etienne

Hi, Etienne.

A little more context might help me provide better guidance (are the teams working on different areas, e.g., API, Web UI, Mobile app, etc. and on the same or different projects and are some of them true "subteams" of a larger team) but that won't stop me from trying. All data meant as an example -- you'll need to adapt appropriately. Because RTC is highly configurable to fit how your teams work -- and is meant to so that you can work as effectively as possible -- it can be difficult to provide generic advice.

Everyone being on the same time line certainly helps -- this means plans cover the same period and can be summarized in higher level plans and reports cover the same period so the data from them can be better compared. So your time line can be a simple series of Sprints for the Release. Hoping that your project is successful and merits additional Releases, you may want to plan ahead and have nested iterations:

Release 0.8 (alpha)
-- Sprint 1
-- Sprint 2...
Release 0.9 (beta)
-- Sprint 1
-- Sprint 2...
Release 1.0...

Each team should have its own Team Area and it might make sense to have a "root" team area other than the Project Area for a project of this size. That way the Project Area can have members such as stakeholders and managers who need visibility but don't get assigned work and Team Area membership can be restricted to people who get assigned work items. The "root" team area could be empty of members or may include leaders who have cross-team work to manage. As an example only:

Project X Team (team area)
--API Team
--DB Team
--Web UI Team
--Mobile Team
----Android Dev
----iOS Dev
--DevOps

And you'll need to configure Work Item Categories that allow work to be Filed Against the appropriate team.

When you create a Plan, you configure an Owner (team area) and an Iteration (sprint X). In this scenario, you'd create a plan for each team and iteration where work needs to happen (so you may or may not create a "Mobile Team" plan depending on whether there's an actual team at that level doing work).

And don't forget Dashboards. They are a valuable way to highlight progress and identify things that need attention. These can be configured at project, team, and personal levels.

And to your question about allocation, if you have people working on multiple teams, they will need to adjust their work allocation to reflect their availability to the teams they are on so that Load and Progress bars can be calculated properly. Since Scrum's effectiveness hinges on the team's commitments, be careful about having people with "divided loyalties".

Hope that helps you get started. Here are some articles that may be useful:

https://jazz.net/projects/rational-team-concert/features/planning
https://jazz.net/library/article/589
https://jazz.net/library/article/587

<snip>

A small question: I need a Sprint X backlog because we need a container where to put the Sprint stories before dispatching them to the team. Do I simply create a Sprint X - Backlog?

Your project has a Backlog iteration -- more than one team can have a plan there. I presume you mean a Product or Release Backlog (your Sprint "plan" is the "backlog" for the Sprint -- just a Scrum naming thing).

Not knowing how your work is configured, it is typical for a project to have a single Product Backlog containing all desired features, enhancements and defects. Some portion of these are scheduled for each Release. Some portion of those scheduled for each Sprint. A Release or Product Backlog owned by a parent team can show all work in the child teams.

Using your example, you could structure it this way:

Team Area Squads
-- Team Area Alpha
-- Team Area Bravo...

If you make a Release Backlog and have Team Area Squads be the owner of the backlog/plan, it will show the work assigned to Alpha, Bravo, etc. for the Release (assuming you have a parent iteration for the release to associate it with). To see the work across an iteration, you can even have a Sprint Backlog/Plan associated with Team Area Squads.

Hi Millard

My understanding of your model is: "one timeline" with multiple releases/iterations, and multiple teams maps to multiple "File Against".

Another question from Etienne is: can team A has a sprint of one months, and team B has a sprint of two months? In this case, do we need two timelines?

Team A and B are working on different areas (e.g. front end and back end, but lose coupled) of the same project and finally they have to be integrated and released together.

Thanks
Jirong

Hi Millard

My understanding of your model is: "one timeline" with multiple releases/iterations, and multiple teams maps to multiple "File Against".

Another question from Etienne is: can team A has a sprint of one months, and team B has a sprint of two months? In this case, do we need two timelines?

Team A and B are working on different areas (e.g. front end and back end, but lose coupled) of the same project and finally they have to be integrated and released together.

Thanks
Jirong

Iterations are defined on the timeline. If you want "concurrent" iterations of different lengths, you will need different timelines. That would add some complexity to your setup that may not be worth it. IMO, if you are on the same project, you should be on the same timeline. Cadence matters.

A month is already a pretty long iteration (assuming you plan to use Scrum and be Agile and have frequent retrospectives to drive continuous improvement, get frequent stakeholder feedback on working software, etc.). I'd also be a bit worried about only integrating the code once every 2 months. Back when I wore an Agile trainer's hat our advice was that your iterations should be short enough that they are almost painful -- because that pain identifies what most needs improvement.