Monday, March 17, 2025

Scrum at Scale with CIPSA: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile (Part - 2)


In the previous post, we learned about:

  • Synchronized Sprints in CIPSA
  • Stock-Trading System's Product Backlog (single one)
  • Planning and Addition of Sprints
  • Seggregation of Individual Scrum Teams
In this post, we learn how to combine them and manage Scrum at Scale. It's the concluding part. 

The contents are from ManagementYogi's Certified In Practical Scaled Agile (CIPSA) Course. You can download and read the CIPSA framework guide for free here.


***

Add the Individual 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 *** UPDATED ***

Scaling is complex, but the framework need not be complex. Scaling 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 practical scaled agile framework – in this case CIPSA, 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.

The series is concluded. 

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


--

This article was first published by MPUG.com on September 4, 2024. This is an updated version.


References

Wednesday, March 12, 2025

Scrum at Scale with CIPSA: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile (Part - 1)


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-sha’) 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 *** UPDATED ***

In the CIPSA framework, when you team-level Scrum, it’s called CIPSA Scrum Framework and when team-level Kanban is used, it’ll be CIPSA Kanban Framework. The CIPSA Scrum Framework is 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 in CIPSA *** UPDATED ***

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, noted below:

  • 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. It’s the sum of all team increments.
  • 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. 

You can plan for as many Sprints as you want for the CIPSA team. MS Project Agile software provides this capability. 

Segregate the Individual 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.

--


References

Sunday, March 09, 2025

Webinar Series: Scrum at Scale with Hands-on Practical Applicability


In a recent article for Scrum at Scale – CIPSA Key Roles and Goals, I wrote about the power of simplicity. I also said simple is beautiful and simplicity sticks. It's applicable in all walks of our lives. You can read it here.

Simple people are liked more, trusted more. Simple things are easily remembered and hence followed. Simple, elegant dresses are natural and indeed, beautiful. Simple manners, for example just a simple and genuine 'thank you' goes a long way many times with the right people in the right environment. 

In any human endeavor, simplicity is a powerful tool. A simple message is more effective and efficient than a long, complicated message. A simple person or organization is easier to work with than a complicated one. However, to make things simple is not that simple. In fact, it' very hard, long-drawn and has to be cultivated. 

The Certified In Practical Scaled Agile (CIPSA) framework strives to be simple. I believe it's the simplest possible framework for Agile at Scale in the world. In addition, it's the only practical Scaled Agile framework in the world.

As shown above, the CIPSA Scrum Framework extends team-level Scrum in a minimal possible way. There are no layers and layers of backlogs, layers and layers of roles and events. If you read the CIPSA Guide – free to download and use, you’d immediately notice these:

  • The roles are just two.
  • The goals are just two.
  • The events are just a few.
  • The artifacts are just three.

Considering multiple Individual Scrum Teams and agile at scale, it’s a simple, yet powerful framework. If you know the Scrum approach, you’ll understand quickly understand the CIPSA Scrum Framework. In addition, the CIPSA framework can use any software tool, including MS Project Agile. 

In my upcoming webinar series conducted by Mastering Projects for Unlimited Growth (MPUG), you’ll learn about scaling, aspects of scaling, other scaling frameworks, the CIPSA Framework (specifically the CIPSA Scrum Framework), various parts of the framework and more. In the final part, we will also see practical, hands-on demonstrations. 

Join me in these three-part webinar series to know more on Scrum at Scale using the CIPSA Framework. The links are noted below. Registration is currently open. 

Below are the event details.

Part - 1: Understanding Scaling with Scrum

Part - 2: Scrum at Scale with the CIPSA Framework

Part - 3: Scrum at Scale with CIPSA and MS Project Agile

Note: You need not have in-depth knowledge of Scrum to understand Scrum at Scale with CIPSA. Also, if you don’t know anything at all about Scrum, you can join, too. We will have a brief discussion on Scrum. 

Join from the first series onward to really understand. 

--

The contents of this webinar series are taken from Certified In Practical Scaled Agile (CIPSA) course . This is the only practical, hands-on, scaled-agile certification course in the world.


References

[1] New Practical Scaled Agile Framework - The CIPSA Framework, by Satya Narayan Dash

[2] Understanding the CIPSA Scrum Framework, by Satya Narayan Dash

[3] Certified In Practical Scaled Agile (CIPSA) course, by ManagementYogi.com