Using Multiple Teams within a Team Project

As the name Team Project suggests, it is normal practice to give each Team its own Team Project.

However, if you have several Teams working on a single Product, you may want them all to use the same Team Project so that reports such as the Product Burndown Chart provide management with a view of progress on the Product as a whole.

Multiple Teams on each Sprint

The recommended way to work with multiple teams in a Team Project is for them all to work on Sprint 1, then Sprint 2, etc.

The alternative is to run a Sprint for each team, so that you have several Sprints running at the same time. If you choose to do this, it is important not to have duplicate Sprint numbers, e.g two Teams with their own Sprint 3, as this will produce inaccurate reports.

There is the added disadvantage that those reports which default to the "current" Sprint will simply choose the first current Sprint. This will only be correct for one Team, and there is no guarantee that the same Team will be chosen for the next Sprint.

Preparing a Multi-Team Sprint

Before you start the first Sprint, you must set the Teams up as described in the previous section. Before each Sprint, you need to:

• Create a Sprint record and give it a unique number
• Mark each Product Backlog Item (PBI) with the number of the new Sprint
• Add Sprint Backlog Items (SBIs) for any PBI that hasn't been decomposed into SBIs already
• Mark each SBI with the new Sprint number
• Link each SBI to the corresponding PBI via the Links section in the query output
• On each PBI, set the Owned By field to the correct Team

Please note that when linking SBIs and PBIs, it does not matter whether you select a PBI and add SBIs to it, or select an SBI and add a PBI to it. Each SBI should be linked to only one PBI. The Sprint Burndown Chart ignores links that are not PBI-to-SBI, but if an SBI is linked to multiple PBIs, the Chart makes an arbitrary choice as to the owning PBI.

You can check that all SBIs have been correctly allocated by running the Product Backlog Composition report. If any SBIs appear in an Orphans section in the new Sprint, these need to be allocated.

Filtering by Team

By default, all the reports initially ignore Team ownership of Backlog Items. The following reports provide a dropdown list of Teams so that you can filter the report by Team:

• All Product Backlog Items
• All Sprint Backlog Items
• Product Burndown Chart
• Sprint Burndown Chart
• Retrospective Report
• Sprint Overview Chart
• Sprint View

Please note that when used in filtered mode, these reports will only product accurate results if

• All active SBIs are correctly linked to PBIs
• All active PBIs are correctly linked to Teams

Limitations

Cross-Linking

Please do not be tempted to try to get the best of both worlds by cross-linking Backlog Items, i.e. linking the SBIs in one Team Project to the PBIs in another Team Project.

Whilst Team System allows you to do this, cross-linking is not supported by Scrum for Team System and will produce unpredictable results.

Reallocating Product Backlog Items

If a PBI is being worked on by one Team and you allocate it to a different Team, it is a limitation of the current implementation that all history for the PBI will then belong to the new Team.

In other words, the PBI and its SBIs will contribute to the Burndown charts as if all the work on them had been undertaken by the new Team.