Scrum is fundamentally a single team-based Agile framework. In fact, per the latest Scrum guide, it’s suitable for a team of ten or fewer people. But in reality, large and complex products or solutions demand larger teams to achieve quicker delivery times and meet the market’s narrow competitive windows. In other words, Scrum at Scale is a necessity, not a desire.

Now, to consider Scrum at Scale, one must consider all the building blocks of Scrum – the events, artifacts and roles (accountabilities). For example, considering events, Scrum at Scale requires planning, reviews, retrospectives, and daily stand-ups at scale.

While all aspects of Scrum are necessary, this article will focus on scaling for planning, specifically Sprints. While doing so, as our focus is on practical, hands-on applicability, we will first explore Multi-Sprint, Multi-Team management with the CIPSA framework. CIPSA (pronounced ‘sip-shaa’) stands for Certified in Practical Scaled Agile and extensively uses MS Project Agile software tool to do scaling. You can download and read the CIPSA framework guide for free here.

Sprints at Scale with Multiple Teams

Though CIPSA Framework considers both Scrum and Kanban at the team level, in this case, we are going to specifically use Scrum. This is known as the CIPSA Scrum Framework, shown below.

A single Product Backlog is cross-team refined and presented with the Product Goal to the CIPSA Team (sum of all Scrum teams) in the CIPSA Sprint Planning meeting. In this meeting, the “what” items to be delivered in the upcoming Sprint is decided. The items are taken from top of the Product Backlog and individual Scrum teams will execute the work items.

The below video [duration: 3m:22s] sheds light on how multiple Scrum Teams will tackle a single Product Backlog, take the backlog items, and execute them in respective individual Sprints. Watch this video before proceeding with the article to have better clarity. For the best experience, go full-screen HD mode and plug in your earphones.

Synchronized Sprints

Did you realize in the above video explanation that the Sprints across the teams are synchronized? It’s a key point to understand and apply. 

The Sprints are not only of same duration, but also have similar Sprint Start and Sprint Finish dates. This is important for a number of reasons:

• All Scrum teams and its members understand that they are progressing towards the same goal in the current Sprint, which in our case is the CIPSA Sprint Goal. Do note that individual teams can have separate Team Sprint Goals.
• While increments can come at any point during the Sprint, the final Integrated Increment, i.e., CIPSA Integrated Increment will come at the end of the Sprint.
• With disparate and uneven Sprint lengths, the individual teams tend to optimize locally, not for the product/system as a whole. But with the same length of Sprint and synchronization, co-operation among teams increases.

Next, we will execute this process step-by-step with MS Project Agile.

Our Product Backlog

In our case, we are building a large Stock-Trading system, on which multiple Scrum Teams will be employed. It’s shown below in the Sprint Planning Sheet view, which can be opened by going to Sprint Tools > Sprints tab > Views group and choosing the respective command from Planning drop-down list. 

The Product Backlog has gone through the initial cross-team Backlog Refinement meta-event (which we saw earlier in the first video) and all high-priority items are towards the top. However, at this stage, the backlog items are not out into individual Sprint buckets and are not associated with the Scrum Teams.

Plan and Add the Sprints

To add Sprints across the Scrum teams, go to Sprint Tools > Sprints tab > Sprints group and use the Manage command. Remember to use the available Sprints template to create the plan. Otherwise, you can add the Sprints from Gantt Chart tools > Project tab > Manage Sprints command. For our case, each Sprint will be two weeks in duration with the same start and finish dates.

As shown:

• We have 5 Sprints planned for and added into our plan.
• Sprint 1 starts on Mon 10/5/26. Each Sprint is two weeks in length.
• Subsequent Sprints are planned and added in similar fashion. 

Segregate the Scrum Teams

In this step we will divide the CIPSA team into three Scrum Teams: Team A, Team B and Team C, working on our single Product Backlog. For that we will add a Team custom field, taking the text custom field. You can create this field by going to Task Sheet Tools > Format tab > Columns group > Custom Fields command > Task custom fields. This is shown below.

As shown, we have taken the Text1 custom field and renamed it as “Team.” Next, we will use the “Lookup…” command in the above view to add the team details.

As clearly shown above, we have three separate Scrum Teams – Team A, Team B and Team C. These teams are part of the larger CIPSA team but will work in different backlog items on the single Product Backlog. The values in the Lookup table are:

• Team A, for work items assigned to Team A.
• Team B, for work items assigned to Team B.
• Team C, for work items assigned to Team C.
• All Teams, for work items assigned to the CIPSA Team.
• Unknown, for work items not yet assigned. This will be the default value.

You may be wondering what items will be for “All Teams”?

It’ll be work items such as CIPSA Sprint Planning, CIPSA Sprint Review, CIPSA Sprint Retrospective, among others. These are meta-events and not specific to individual Scrum Teams.

Add the Scrum Teams

In this step, we will associate the work items with the respective Scrum teams. This will be decided in the CIPSA Sprint Planning meeting, where the “what” part is decided. Do not confuse this meeting with an individual Team Sprint Planning meeting, which happens later. It’s the CIPSA Sprint Planning, during which the planning is taking place at scale.

To have the work items associated, add a new column into Sprint Planning Sheet view and associate with respective Scrum teams. Next, choose the team from the drop-down list and associate it with respective work items.

Associate the Sprints the Scrum Teams

Our next step is to associate the planned Sprints with the individual Scrum Teams.

To associate the teams with Sprints, select the Sprint column available in the Sprint Planning Sheet view and select the Sprint number from the drop-down list. This is shown in the below figure. While we have planned for five Sprints, our upcoming Sprint is Sprint 1 and each team will Sprint on its own with this Sprint number – Sprint 1.

In the above figure, again, did you notice that all teams will be sprinting on the same Sprint, i.e., Sprint 1?

This is a significant point to understand. There are no separate Sprints for separate teams. Rather the Sprint Planning is happening at the Global Level for all the teams and then we are associating the Sprints with the teams.

An alternative and relatively familiar view for many of you will be the Gantt Chart view. This is depicted in the below figure.

In the above figure, I’ve added three new columns:

• Built-in field of “Sprint” informing the Sprint number.
• Built-in field of “Sprint Start” and “Sprint Finish” which shows that the features across the teams are to be completed within the Sprint duration.
• The custom field of “Team” shows the feature distribution across Scrum teams.

As explained earlier in the first video, the CIPSA Sprint Planning will be succeeded by the individual Team Sprint Planning event and tasks will be further decomposed. When the respective sub-tasks are added, the CIPSA Sprint Backlog will be the sum of all individual Team Sprint Backlogs. This is shown in the below figure.

The above highlighted areas in the figure is the CIPSA Sprint Backlog, consisting of individual Team Sprint Backlogs. This backlog will get progressively built-up with CIPSA Frameworks’ meta events and other events.

Again, the key points to note here are these:

• All Scrum Teams are sprinting on the same Sprint – Sprint 1. But they are executing the work items separately.
• All Scrum Teams are sprinting towards the same CIPSA Sprint Goal, which is in sync with the Product Goal.
• Individual Scrum Teams will have individual Team Sprint Goals, but these goals must be in sync with the CIPSA Sprint Goal.

Demonstration: Scrum at Scale using CIPSA Framework

Let’s have a demonstration of what we have learned so far with our practical scaled approach using Scrum to deliver a product. The below video [duration: 7m:19s] demonstrates such scaling with MS Project Agile. Again, plug-in your headphones to understand with more clarity.

Conclusion

Scaling is complex. It involves complex cross-team dependency management, collaboration, multi-Sprint management, multi-team tracking, board management, integration of individual team increments and above all, delivering value to the customer or end user. However, with the right software tool, much of the heavy lifting can be done.

A big misconception in Agile practitioners’ circles is that MS Project is not at all suitable for Agile at Scale, not just Agile! As we just reviewed in this article, MS Project Agile can effectively be used to scale multiple Scrum Teams with multiple synchronized Sprints and deliver complex products.

I welcome your thoughts, comments, and feedback in the comments section below and the Community Discussion Forum.

References

[1] NEW: Certified In Practical Scaled Agile (CIPSA) Framework Guide, by Satya Narayan Dash

[2] Scrum and Microsoft Project: Agile Project Management Training, by MPUG.com

[3] Online Course: Mastering MS Project Agile, by Satya Narayan Dash