Scaling frameworks should be simple but will be used to deliver complex work. Scaled roles should be small in number, but will be used to deliver big solutions. This also ensures a flat hierarchy and dismantles bureaucracy. Scaled events should be minimal, but the productivity should be maximal. I believe in it because simple is beautiful. In fact, simplicity sticks.

Indeed, some of the most beautiful things in the world are simple, yet powerful. The Sydney Opera House, when seen from outside, looks like nested flower petals. It’s simple, yet a beautiful architecture and projects a powerful image of Sydney harbor.

Microsoft’s Bing is a powerful search engine and now loaded with gen-AI search, yet has a very simple user interface (UI). It’s only a textbox to do your search. That’s it! Think about it for a moment. Can it be simpler than that?

Agile at Scale is no different.

Let me also inform you, to make things simple is not that simple! It’s actually very hard. It takes enormous time and effort, practice, a number of iterations with feedback.

The Certified In Practical Scaled Agile (CIPSA) framework strives to be a simple one. It extends both team-level Scrum and team-level Kanban, in a minimal way in all aspects – be it events, roles, artifacts or others.

In this article, we are going to follow the CIPSA Scrum Framework. Here it’s specifically about scaling of roles and goals for Scrum at Scale. To understand the basics of this Practical Scaled Agile framework, you can check this article, specifically the first  video in brief. You can also download the CIPSA Framework Guide for free here.

Two Key Roles in Scaled Scrum

Considering Scrum, the CIPSA Scrum framework adds only two new roles at scale:

• Chief Product Owner (CPO)
• Principal Scrum Master (PSM)

The CPO role is unique to CIPSA. The CPO is accountable for the Product Backlog. The CPO may be a dedicated individual or someone from the Product Owner Team (i.e., team of Product Owners from the individual teams) can play this role. The CPO creates a single, ordered backlog. The items from the backlog will be the deliverables by all teams.

The CIPSA Cross-Team Backlog Refinement and CIPSA Sprint Review meta-events are led by the CPO, with other product owners and needed representatives from the individual teams.

The PSM role is also unique to CIPSA. The PSM is accountable for the entire CISPA process. He or she focuses on the progress and helps in prioritization as well as removal of cross-team impediments. The PSM is also responsible for continuously improving the effectiveness of CIPSA processes. The PSM may be a dedicated individual or someone from the Scrum Master Team, i.e., a team of Scrum Masters from the individual Scrum teams.

The CIPSA Sprint Planning and CIPSA Sprint Retrospective meta-events are led by the PSM, with other Scrum Masters (SM) and the needed representatives from the individual Scrum teams.

As the role of CPO and PSM can be confusing for aspiring CIPSA certified professionals, the best way to know these roles is with the next two sections – what it is and what it’s not. 

The Role of CPO – What it is and is Not

The CPO sets the product vision, which is strategic and is aligned with organizational vision, mission and strategic objectives. The CPO is accountable for creating a single, ordered product backlog, which will be worked-upon by individual Scrum teams.

Now, the following differentiations inform what a CPO is not and what a CPO truly is for Scrum at scale:

• The Chief Product Owner does not get the product vision from the top executive team. The Chief Product Owner sets the product vision.
• The Chief Product Owner is not a portfolio or program manager. The Chief Product Owner is the visionary for the Product.
• The Chief Product Owner is not a backlog maintenance person. The Chief Product Owner is the main backlog strategist.
• The Chief Product Owner is not a lone-wolf. The Chief Product Owner works with other Team Product Owners, stakeholders and customers.

The Role of PSM – What it is and is Not

The PSM ensures (i.e., accountable) the CIPSA meta-events take place, conducted in the right way and within a timebox. After all, the PSM is accountable for the CIPSA process. The PSM also improves the effectiveness of the Scaled Scrum, such as higher quality, lesser number of bugs and lower cost.

To make this role clearer, the following differentiations outlines what a PSM is not and what a PSM actually is for Scrum at scale:

• The Principal Scrum Master is not the manager of the CIPSA team. A Principal Scrum is a true leader who serves the team and organization.
• The Principal Scrum Master is not concerned about intra-team dependencies. The Principal Scrum Master focusses on inter-team dependencies.
• The Principal Scrum Master does not track the individual Team Increments. The Principal Scrum Master tracks the overall product work and progress.
• The Principal Scrum Master is not concerned about individual risks arising from individual teams. The Principal Scrum Master is concerned about the cross-team risks.

Figurative Representations – Scaled Scrum Key Roles

Let’s see how the CPO and PSM are part of the entire CIPSA team. The below figure represents these rolls within the team.

As shown above:

• We have three Scrum Teams: Scrum Team A, B and C. Each team has its own individual team members.
• At scale, the CIPSA team has the Chief Product Owner (CPO).
• At scale, the CIPSA team also has the Principal Scrum Master (PSM).
• The CIPSA team is considered to be a single entity and there is no throw-over-the-wall mentality.

You might be wondering about the individual Scrum teams’ roles. The below figure shows a high-level view.

As shown above:

• Each Scrum team will have roles such as Product Owner (PO), Scrum Master (SM) and developers or team members.
• There can be some specialized roles, but then also do remember that the team members are generalizing specialists with broken-comb skill sets.
• While the individual Scrum teams have their own goals and deliverables, they have to integrate for the entire CIPSA team.

At scale, I’ll be not focusing on the individual roles, as the focus is on the entire CIPSA team, CIPSA integrated increment, cross-team risks, cross-team dependencies etc. 

Using MS Project Agile

Now, let’s see how MS Project Agile can be used to have all the roles (resources). MS Project comes with a very simple, yet effective view – the Resource Sheet view. This view will be used to add the necessary resources, who play the desired roles.

After you add the resources for all the Scrum teams, the view will come as shown below.

As shown:

• We have 18 resources across multiple Scrum teams.
• Various resource related fields are populated by default.
• For your Scaled Scrum work, you can also add other resources such as material and/or cost.

Next, to differentiate among the teams, we need to have a new Team custom field. This field can be added by going to Resource Sheet Tools > Format tab > Columns group > Custom Fields command.

One can add the teams separately, but it’s better to have a look-up for the custom field. This can be done by using the “Lookup …” button highlighted in the above figure.

As shown above, for the Team Custom Field, we have five values:

• Team A, B and C for resources of Team A, B and C.
• Unassigned for unassigned resources.
• All Teams will be resources used across the teams. For roles such as CPO and PSM, it will be an apt choice.
• Unassigned has been set as the default one and hence the blue color coding.

Ensure that the Lookup radio button is enabled so that the values can take effect and will be available in the drop-down list. Next, we can populate this new Team custom field in our Resource Sheet view with the respective team values. The Team column has to be added into the existing list of columns in the view. Post population, it’ll come as shown below.

In addition, we can also associate the resources to the roles being played. The role can be added into the Group field, available by default or one can add a separate custom field. This is shown in the below figure.

As you’d have noticed, three resources are part of the entire CIPSA team (informed as “All Teams”):

• John Robinson, a work resource, is the Chief Product Owner.
• Satya Dash, a work resource, is the Principal Scrum Master.
• Other resources have team specific roles and accountabilities.

Goals in Scaled Scrum

Roles and goals are intricately related. Without clear roles and responsibilities (accountabilities), you won’t have clear goals.

As a matter of fact, I’ve interacted with many Scrum Masters and Product Owners, who don’t have any goal at all for their Sprints. It’s like getting into a train or bus, but without any end destination in mind! Ever travelled like that in any seriousness?

So, who will set the Goals and where? The goals are associated with the artifacts – Product Backlog, CIPSA Sprint Backlog and Team Sprint Backlog.

• Goal for the product will be set by the Chief Product Owner. The Product Goal is part of the Product Backlog. The CPO also prepares the Product Goal and presents it to the CIPSA Team in the CIPSA Sprint Planning meeting.
• Goal for the upcoming CIPSA Sprint meta-event will be set by the CIPSA Team. The CIPSA Sprint Goal is part of the CIPSA Sprint Backlog.

Goals for the upcoming Team Sprint events will be set by the individual and respective Team Product Owners. The Team Sprint Goal is part of the Team Sprint Backlog.

Video – Key Points Recap

Now, it’s a good time to recap what we have learned so far with the help of MS Project Agile software tool. To support this, I’ve provided the following video [duration: 4 minutes approx.]. For the best experience, you may want to go full-screen with HD mode and plug-in your earphones.

Conclusion

In the beginning, I wrote: Simple is beautiful. It is applicable to many aspects of our lives, too. For example, as a kid, did you like the simple game of baseball, cricket, and/or badminton, or the complex game of synchronized swimming with eight or ten people and rules? I’m not saying synchronized swimming is not good, but which one did you mostly follow? You know the answer!

The CIPSA framework is intended to be simple, so that it can be followed easily. More importantly, it’s hands-on and practical. This can be used with any software tool, which provides Agile at Scale capability. MS Project Agile does that and hence it’s used. Of course, it can be used with any other software tool providing proper scaling capabilities.

In my upcoming webinar, we’re going to learn the fundamentals of scaling, the roles and responsibilities, and the events followed with a hands-on demonstration in the final part. Join me in the upcoming webinar series to learn more.

Learn More + Earn PDUs!

Satya Narayan Dash is presenting a three-part series to dive deeper into this topic. Register below and join us!

March 12, 2025: Scaling Scrum with Hands-on Applicability: Understanding Scaling with Scrum (Part 1)

March 19, 2025: Scaling Scrum with Hands-on Applicability: Scaled Scrum with CIPSA Framework (Part 2)

March 26, 2025: Scaling Scrum with Hands-on Applicability: Hands-on, Scaled Scrum with MS Project (Part 3)

References

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

[2] Scrum at Scale: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile, published by MPUG.com

[3] Scrum at Scale: Product Backlog, CIPSA Sprint Backlog and Team Sprint Backlog with MS Project Agile, published by MPUG.com

[4] Scrum and Microsoft Project: Agile Project Management Training, hosted at MPUG.com

[5] The CIPSA Framework – A Simple Clock View, by Satya Narayan Dash