Practical Scaled Agile (CIPSA) Certification: CIPSA Kanban Backlog – What It Is and What It Is Not!

 

Both the Product Backlog and the CIPSA Kanban Backlog are key artifacts in the CIPSA Kanban Framework. However, from an execution point of view, the real action happens in the CIPSA Kanban Backlog, because it is the CIPSA Kanban Backlog that is executed by the CIPSA Kanban Team.

Product backlog items taken from the Product Backlog are executed by individual Kanban Teams, resulting in a CIPSA Integrated Increment at the end of the release. The following differentiations clearly define the characteristics of the CIPSA Kanban Backlog. 

The content of this article is based on the CIPSA Kanban Framework. See here. 

Exhaustive explanation is part of the CIPSA certification course. See here. CIPSA is world's only Practical Scaled-Agile certification. It supports both Scrum and Kanban.

To read all articles of this series use this link: 
What It's and What It's Not series for CIPSA

CIPSA Kanban Backlog – What It’s and What It’s Not

Among many, the following are some of the top ones:

1. Not Ongoing, but Release-Bound: The CIPSA Kanban Backlog is not a continuous artifact. The CIPSA Kanban Backlog is discarded when the Release ends.

The CIPSA Kanban Backlog is not kept for indefinitely and is not ongoing is nature. When one release is over, it’s discarded and another is taken-up. 

2. Not a Superset, but a Subset: The sum of all CIPSA Kanban Backlogs across Releases is not equal to the Product Backlog. The CIPSA Kanban Backlog is a smaller, Release-specific subset.

There will be multiple releases while using the CIPSA Kanban Backlog. The sum of all CIPSA Kanban Backlog across releases doesn’t equal to the Product Backlog. It’ll always remain a subset of the Product Backlog. See here to learn more.

3. Not Just Tasks, but also Meta-Events: The CIPSA Kanban Backlog does not only hold work items. The CIPSA Kanban Backlog also includes CIPSA Meta-Events.

Other than the work items, the meta-events included in the CIPSA Kanban Backlog can be CIPSA Kanban Planning, CIPSA Daily Stand-ups, CIPSA Kanban Review, and CIPSA Kanban Retrospective.

4. Not Self-Directed, but Facilitated: The CIPSA Kanban Backlog is not managed without guidance. The CIPSA Kanban Backlog is facilitated by the Principal Flow Master (PFM).  

While the CIPSA Kanban Team owns the CIPSA Kanban Backlog and the team-members execute the tasks (from the individual Team Backlog), it’s not without guidance. The PFM provides the necessary guidance. See the PFM video here. 

5. Not Isolated, but Dependency-Aware: The CIPSA Kanban Backlog does not ignore inter-team needs. The CIPSA Kanban Backlog allows inter-team dependencies to be noted and tracked.

The inter-team dependencies, i.e., the dependencies across the individual Kanban Teams are noted in the CIPSA Kanban Backlog. With right software tool(s), it’s highly useful. 

CIPSA Kanban Backlog – Summary Table

The summary table is shown below.

Final Words

I believe the above differentiations will bring a lot of clarity regarding the CIPSA Kanban Backlog. Detailed explanations will be part of the CIPSA certification course.

Want to experience it hands-on? Become a CIPSA. It’s world’s only Practical Scaled Agile certification.

Among many things, you’ll learn:

• How to build the CIPSA Kanban Backlog?
• How to associate with single- or multi-Releases?
• How to go with both CIPSA Kanban Backlog and Team Kanban Backlogs?
• What are the various ways to assign resources at Scale?
• When, why and how to schedule CIPSA Kanban Backlog related events?

--

CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not - CIPSA

CIPSA Sample Videos and Questions:

[1] CIPSA Sample Video List (Choose a Video)

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Sample Questions:

[1] CIPSA Certification Sample Questions (Part - 1)

[2] CIPSA Certification Sample Questions (Part - 2)

CIPSA Certification:

[1] NEW Scaled Agile Certification Course: Certified In Practical Scaled Agile (CIPSA)

[2] Frequently Asked Questions (FAQs) - CIPSA Certification  

[3] New Practical Scaled Agile Framework – The CIPSA Framework Guide

[4] A Close Look at the CIPSA Kanban Framework – Practical, Hands-on Kanban at Scale

[5] The CIPSA Framework Clock - A Unique Way

Practical Scaled Agile (CIPSA) Certification: CIPSA Sprint Backlog – What It Is and What It Is Not!

While both the Product Backlog and the CIPSA Sprint Backlog are key artifacts in the CIPSA Scrum Framework, the real action happens with the CIPSA Sprint Backlog. It’s the CIPSA Sprint Backlog which gets executed by the CIPSA Team.

The product backlog items taken from the Product Backlog are executed by individual Scrum Teams and a CIPSA Integrated Increment is given at the end of the Sprint. The below differentiations clearly inform the characteristics of the CIPSA Sprint Backlog. 

The content of this article uses the CIPSA Scrum Framework. Similar ones will be applicable to the CIPSA Kanban Framework. 

To read all articles of this series use this link: What It's and What It's Not series for CIPSA. 

CIPSA Sprint Backlog – What It’s and What It’s Not

Among many, I've outlined the following ones for your understanding. Exhaustive explanation is part of the CIPSA certification course. See here.

1 Not Tasks, But Value: The CIPSA Sprint Backlog is not just a list of tasks or line items. The CIPSA Sprint Backlog can contain features, user stories and tasks. 

The CIPSA Sprint Backlog goes beyond a simple task list and focuses on delivering customer and business value. It includes features, user stories, and tasks to ensure a value-driven approach to sprint planning and execution. 

Remember the execution of this backlog finally leads to the CIPSA Integrated Increment. See here.

2. Not CPO-Owned, But Team-Owned: The CIPSA Sprint Backlog is not managed by the Chief Product Owner. The CIPSA Sprint Backlog is managed by the CIPSA team. See here.

Unlike the Product Backlog, the CIPSA Spring Backlog is managed and owned by the CIPSA team. In other words, it’s a collaborative one by the individual Scrum teams. The oversight is provided by the Principal Scrum Master (PSM). See here.  

3. Not Static, But Evolving: The CIPSA Sprint Backlog is not static or fixed. The CIPSA Sprint Backlog can evolve during the Sprint. 

The CIPSA Sprint Backlog is dynamic and can adapt as the Sprint progresses. It allows flexibility to respond to change and emerging tasks or insights. Sometimes, it's highly possible that new tasks can come-up.

4. Not Performance, But Progress: The CIPSA Sprint Backlog is not about measuring the individual team performance. The CIPSA Sprint Backlog is for checking the progress towards the CIPSA Sprint Goal.

The CIPSA Sprint Backlog is used to track progress toward the CIPSA Sprint Goal, not to evaluate individual Scrum Team performance. The focus is on collective delivery, not on individual Team metrics.

5. Not Kept, But Discarded: The CIPSA Sprint Backlog is not going to be retained throughout the project. The CIPSA Sprint Backlog will be discarded at the end of the Sprint.

The CIPSA Sprint Backlog is a temporary one and it's discarded at the end of the Sprint. Its value lies in guiding current work and finally delivering the Integrated Increment.

6. Not Backlog-Led, But Goal-Led: The CIPSA Backlog items do not drive the CIPSA Sprint Goal. The CIPSA Sprint Goal drives the work items in the CIPSA Sprint Backlog.

The CIPSA Sprint Backlog is shaped by the CIPSA Sprint Goal, not the other way around. The CIPSA Sprint Goal is in alignment with the Product Goal (see here). Work items are selected and executed to achieve the CIPSA Sprint Goal, ensuring purpose-driven progress.

Did you properly read the last (previous) one? 

It’s an important one to note. The Product Goal drives “what” will constitute the Product Backlog. Similarly, the CIPSA Sprint Goal drives “what” will constitute the CIPSA Sprint Backlog. The meta-events are added to finalize the backlog.

CIPSA Sprint Backlog – Summary Table

The summary table of what we have learned so far is shown below.

Final Words

I believe the above differentiations will bring a lot of clarity regarding the CIPSA Sprint Backlog. Remember, this is where the real action happens!

Recently, a successful CIPSA informed hands-on learning with .mpp solution files has been invaluable. You can read the CIPSA Success Story.

Want to experience it hands-on? Become a CIPSA practitioner – part of the world’s only practical scaled agile framework.

Among many things, you’ll learn (hands-on):

• How to build the CIPSA Sprint Backlog?
• How to break down backlog items in a proper way?
• How to estimate the items in the CIPSA Sprint Backlog?
• What are the various ways to assign resources?
• When to schedule CIPSA Sprint Backlog related events?
• When and where to include CIPSA meta-events?

CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not - CIPSA

CIPSA Sample Videos:

[1] CIPSA Sample Video List (Choose a Video)

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Sample Questions:

[1] CIPSA Certification Sample Questions (Part - 1)

[2] CIPSA Certification Sample Questions (Part - 2)

CIPSA Certification:

[1] NEW Scaled Agile Certification Course: Certified In Practical Scaled Agile (CIPSA)

[2] Frequently Asked Questions (FAQs) - CIPSA Certification  

[3] New Practical Scaled Agile Framework – The CIPSA Framework Guide

[4] Understanding the CIPSA Scrum Framework – Practical, Hands-on Scrum at Scale

[5] The CIPSA Framework Clock - A Unique Way

Practical Scaled Agile (CIPSA) Certification: Product Goal – What It Is and What It’s Not!

The Product Goal, which is part of the Product Backlog, is an essential element of the CIPSA framework. Though this term is well-known in the Agile community, its usage within a single Product Backlog supporting multiple Scrum or Kanban teams, is often not clearly understood when applied at scale.  

In this article, we will explore what a Product Goal means for a large team and clarify some common misconceptions about this goal. 

Among many, I’ve outlined the following points. These clearly distinguishes a Product Goal for Agile at Scale. Do note that both Product Backlog and Product Goal are commonly used terms for both CIPSA Scaled Scrum and CIPSA Scaled Kanban.

To read all articles of this series use this link: What It's and What It's Not series for CIPSA.

Product Goal – What It’s and What It’s Not! 

1. Not Short-term, but Long-term: The (CIPSA) Product Goal is not short-term. The Product Goal provides a long-term objective to the CIPSA team.

The Product Goal spans beyond immediate Sprints (as in CIPSA Scrum) or Integrated Increments. It offers guidance and path to meet final Product vision.

2. Not Per Team, but Shared: The Product Goal is not per individual teams - individual Scrum teams or Kanban teams. The Product Goal is shared by the entire CIPSA team working on a single product.

All individual teams (Scrum or Kanban) align under one unified Product Goal rather than having separate ones. This promotes cohesion and reduces conflicting priorities.

3. Not Just for CIPSA Team, but for All: The Product Goal is not only for the CIPSA team. The Product Goal provides vision, context and direction to the stakeholders.

The Product Goal informs and involves all stakeholders, not just the CIPSA team. It helps everyone understand the product direction and purpose.

4. Not Many at Once, but One at a Time: The Product Goal is not multiple at a time. The Product Goal is a single objective at a time.

There is only one Product Goal at a time. It ensures focus and clarity. 

5. Not Static, but Evolving: The Product Goal is not static. It changes when needed. When one goal is completed, another is taken up. 

The Product Goal adapts over time based on progress and feedback. Once a goal is achieved, a new goal emerges, continuing the product evolution.

6. Not Outside, but Inside: The Product Goal is not outside of the Product Backlog. Product Goal is part of the Product Backlog.

The Product Goal is clearly embedded within the Product Backlog and evolves with it. Such practice ensures that the goal remains visible and connected to the team's daily work.

7. Not Backlog-Driven, but Backlog-Driving: The content of the Product Backlog does not drive the Product Goal. The Product Goal drives the content of the Product Backlog.

This is another misconception, which needs clarity. The Product Goal shapes what goes into the Product Backlog, not the other way around! It ensures alignment between features to be taken and strategic direction.

Product Goal – Summary Table

In summary, Product Goal is indispensable for the success of the CIPSA team. The Product Goal is the ultimate one to achieve with the help of CIPSA Goals (or CIPSA Sprint Goals) and individual Team Goals (or Team Sprint Goals). 

The above points that we just learned is summarized in the table below.

In Conclusion...

It’s the responsibility of the CPO to clearly communicate and emphasize the importance of the Product Goal. The CPO is accountable for it. For the CPO role, see here. 

On the other hand, it is the responsibility of the CIPSA Team and individual teams to achieve the Product Goal through CIPSA Goals and individual Team Goals. Mark the extra "s" in other goals.

In other words, for one Product Goal (one objective at a time), there can be multiple CIPSA Goals and individual Team Goals.

The above explanations are only partial. Want to dive deeper? Consider becoming a CIPSA. When you subscribe to this course, you’ll learn:

• What are the other uses of a Product Goal?
• How do you define and add a Product Goal?
• Where and when should it be added?
• How can it be used by the CIPSA team?
• How can it be used by the individual Scrum or Kanban teams?
• And more.

To reiterative, the CIPSA certification is not only highly practical with a large number of exercises and solution files, it also comes at a very low cost.

CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not - CIPSA

CIPSA Sample Videos:

[1] CIPSA Sample Video List (Choose a Video)

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Sample Questions:

[1] CIPSA Certification Sample Questions (Part - 1)

[2] CIPSA Certification Sample Questions (Part - 2)

CIPSA Certification:

[1] NEW Scaled Agile Certification Course: Certified In Practical Scaled Agile (CIPSA)

[2] Frequently Asked Questions (FAQs) - CIPSA Certification  

[3] New Practical Scaled Agile Framework – The CIPSA Framework Guide

[4] Understanding the CIPSA Scrum Framework – Practical, Hands-on Scrum at Scale

[5] The CIPSA Framework Clock - A Unique Way

Practical Scaled Agile (CIPSA) Certification: The Principal Flow Master (PFM) – What It Is and What It’s Not!

 

In the CIPSA Kanban (not Scrum!) Framework, one key primary role is that of the Principal Flow Master (PFM). Very few Scaled Agile frameworks, if any, support team-level Kanban. CIPSA is unique not only in its practical, hands-on, tool-driven approach but also in its support of Kanban.

As the PFM role is new and not available in most Scaled Agile approaches, it is often misunderstood. Note that this role is unique to CIPSA certification.

In this post, we will learn more about the PFM role and how it differs from the individual team-level Flow Master. In addition, we will explore what this person actually does. This post explains “what it is and what it is not” to bring more clarity.

To read all articles of this series use this link: What It's and What It's Not series for CIPSA.

Among many, following are a few.

Principal Flow Master – What It Is and What It’s Not

1. Not a Manager, but an Enabler: The Principal Flow Master is not the manager of flow for the CIPSA team. The Principal Flow Master enables the flow for the CIPSA team.

This role of the PFM is not about command and control, but about creating the conditions for flow to happen naturally for the CIPSA Kanban team. 

2. Not Intra-, but Inter-team: The Principal Flow Master is not concerned about intra-team bottlenecks. The Principal Flow Master is focused on inter-team bottlenecks (in flow).

The focus of the PFM is on how teams interact, not how they operate individually. The PFM looks for inter-team bottlenecks and works to remove them. 

3. Not Team Metrics, but Product Flow: The Principal Flow Master does not track the individual Kanban team Increments. The Principal Flow Master tracks the overall product work and progress.

The PFM does not micro-manage team Increment or team-metrics, and indeed, he or she plays no role in that! The goal is to maintain visibility into the flow of value at the product or system level.

4. Not Local Fixes, but Systemic Resolution: The Principal Flow Master does not check for the issues and impediments within individual teams. The Principal Flow Master ensures resolutions of cross-team issues and removal of cross-team impediments.

It’s well-known in management that local issues are best handled by the team itself. The Principal Flow Master, on the other hand, focuses on complex, multi-team issues that block the CIPSA Team’s overall flow.

5. Not Individual Team Risks, but Cross-team Risks: The Principal Flow Master is not concerned about individual risks arising within individual teams. The Principal Flow Master is focused on cross-team risks.

Cross-cutting risks can impact multiple areas and jeopardize delivery. It’s the job of the PFM to manage the. By managing them, the CIPSA Team can have smoother coordination and predictability.

6. Not Setter, but Facilitator of WIP Limits: The Principal Flow Master does not set the work in progress (WIP) limits. The Principal Flow Master supports the team in deciding the WIP. 

WIP can be set for the workflow states in the CIPSA Kanban Board. The CIPSA Team is trusted to self-regulate their capacity. The PFM’s role is to facilitate, not impose it.

Principal Flow Master – Summary Table

The following table contrasts common misconceptions with the true nature of the role of PFM, highlighting key differences in focus and approach. 

Live Video Explanation

For the PFM role, I've prepared the below video [duration - 13m: 30s]. I've also explained the false pride in having "branded" certification. A certification should be useful to you. Watch the video alongside this article for a better learning experience. Plug-in your headphones and go full-screen HD.

Conclusion

The Principal Flow Master (PFM) plays a facilitative and enabling role, rather than a directive or managerial one. The PFM’s focus is not on managing individual teams or resolving team-specific issues, but on fostering cross-team alignment, enabling flow, and removing bottlenecks that hinder the CIPSA team’s ability to deliver.

Just as the Principal Scrum Master (PSM) is a key role in CIPSA Scrum (see here), the PFM is also a vital and indispensable role in CIPSA Kanban. Like the PSM, the PFM is a leader who servers the CIPSA Kanban team. However, unlike the Scruma@Scale+CIPSA mindset for the PSM, the thinking here for the PFM must be rooted in Kanban@Scale+CIPSA mindset.

The above list of “what it’s and what it’s not” is a partial and brief one. 

• Want to learn more with hands-on practical software tools?
• Want to know how the PFM is assigned and part of the Flow Master group?
• Want to visualize the workflow across the Integrated Kanban Board at Scale?
• Want to build the Cumulative Flow Diagram (CFD) at Scale?
• Want to resolve overallocations for Kanban at Scale?
• Want to determine the Work in Progress Limit (WIP) at Scale?

To gain in-depth knowledge on all the above and more, consider being a CIPSA! You’ll learn Kanban at Scale in a hands-on manner with direct usage of software tool. The course is thoroughly practical and highly economical.  

CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not - CIPSA

CIPSA Sample Videos and Questions:

[1] CIPSA Sample Video List (Choose a Video)

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Sample Questions:

[1] CIPSA Certification Sample Questions (Part - 1)

[2] CIPSA Certification Sample Questions (Part - 2)

CIPSA Certification:

[1] NEW Scaled Agile Certification Course: Certified In Practical Scaled Agile (CIPSA)

[2] Frequently Asked Questions (FAQs) - CIPSA Certification  

[3] New Practical Scaled Agile Framework – The CIPSA Framework Guide

[4] A Close Look at the CIPSA Kanban Framework – Practical, Hands-on Kanban at Scale

[5] The CIPSA Framework Clock - A Unique Way

Practical Scaled Agile (CIPSA) Certification: The Principal Scrum Master (PSM) – What It Is and What It’s Not!

In the CIPSA Scrum Framework, in addition to the primary role of Chief Product Owner, we also have the Principal Scrum Master (PSM). This role is necessary to have Scrum at Scale with CIPSA. Unlike the Individual Teams’ Scrum Masters, the role and responsibilities of the PSM are different. It’s a very important role to have in order to succeed at Scale. 

In this post, we will explore more on the Principal Scrum Master role as there are a number of misconceptions and misunderstandings. It’s presented in the form of what it is and what is not, to provide greater clarity.  

The following are some of them. To read all articles of this series use this link: 

What It's and What It's Not series for CIPSA. 

Principal Scrum Master – What It Is and What It’s Not

1. Not Manager, but Leader: The Principal Scrum Master is not the manager of the CIPSA team. The Principal Scrum is a true leader who serves the team and organization.

The Principal Scrum Master leads by serving, not managing. The PSM focuses on team and organizational needs.

2. Not Intra-Team, but Inter-Team: The Principal Scrum Master is not concerned about intra-team dependencies. The Principal Scrum Master focuses on inter-team dependencies.

Rather than resolving team dependencies which are internal, the Principal Scrum Master addresses coordination across multiple teams. The PSM manages dependencies that span beyond one individual Scrum Team.

3. Not Team Tracking, but Product Tracking: The Principal Scrum Master does not track the individual Team Increments. The Principal Scrum Master tracks the overall product work and progress.

The focus of a PSM isn't on individual Team Increments, but on the unified or Integrated Increment. This ensures the overall product progress aligns with strategic objectives.

4. Not Fragmented, but Unified: The Principal Scrum Master does not communicate like individual Team Scrum Masters. The Principal Scrum Master is the main communicator for and of the CIPSA Team.

The PSM provides a unified voice to upper management. Communication is consolidated through the Principal Scrum Master. This ensures alignment across teams rather than fragmented messaging from and for each Scrum team. 

The PSM is the main spokesperson for the CIPSA team.

5. Not Reporting, but Enabling: The Principal Scrum Master is not a chief-clerk or secretary responsible for reporting the status. The Principal Scrum Master enables progress for the entire CIPSA team.

The PSM don't just gather updates and report status for the CIPSA Scrum team. The PSM actively remove obstacles and facilitate progress. This role is about driving momentum, not about reporting status as chief-clerk.

6. Not Spot Checks, but Systemic Resolution: The Principal Scrum Master does not check for issues and impediments of individual teams. The Principal Scrum Master ensures that cross-team issues are addressed and cross-team impediments are removed.

Instead of isolated checks, the PSM drives solutions to broader, recurring impediments. It's also about issues impacting multiple teams. The approach taken by the PSM is proactive and system-wide.

7. Not a Replacement, but a Complement: The Principal Scrum Master does not replace the responsibilities of individual Scrum Masters. The Principal Scrum Master complements their efforts by coordinating cross-team work.

The Principal Scrum Master doesn't take over individual Scrum Masters’ roles. Many have this misconception! Instead, he or she coordinates and supports cross-team initiatives. 

The PSM complements, not replaces, the individual Team Scrum Master.

Summary Table – Principal Scrum Master 

For quick remembrance and recall, a summary table is shown below.  

Live Video Explanation

The below video [duration - 10m: 08s] will further consolidate your understanding. Watch the video alongside this article for a better learning experience. Don't forget to plug-in your headphones and go full-screen HD.

Closing Remarks

It’s the PSM who ensures the CIPSA meta-events are conducted in a positive manner and are productive. Do remember that these meta-events are timeboxed. 

While going with Scrum at Scale with CIPSA, the key focus is on the CIPSA Integrated Increment. Ultimately, that’s artifact that matters! The PSM plays an indispensable role in having the Integrated Increment. See here.

• Want to learn more with hands-on practical software tools?
• Want to know how the PSM and CPO are assigned?
• Want to visualize cross-team dependencies for the entire CIPSA team?
• Want to assign resources for Scrum at scale?
• Want to resolve overallocations for Scrum at scale?

Consider being a CIPSA professional. You will get the highest possible return on your investment. 

CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not - CIPSA

CIPSA Sample Videos:

[1] CIPSA Sample Video List (Choose a Video)

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Sample Questions:

[1] CIPSA Certification Sample Questions (Part - 1)

[2] CIPSA Certification Sample Questions (Part - 2)

CIPSA Certification:

[1] Scaled Agile Certification Course: Certified In Practical Scaled Agile (CIPSA)

[2] Frequently Asked Questions (FAQs) - CIPSA Certification  

[3] New Practical Scaled Agile Framework – The CIPSA Framework Guide

[4] Understanding the CIPSA Scrum Framework – Practical, Hands-on Scrum at Scale

[5] The CIPSA Framework Clock - A Unique Way

Practical Scaled Agile (CIPSA) Certification – The Ninjas, The Guide, The Mastermind and The Patron

Scrum at Scale with CIPSA introduces only two key roles – Chief Product Owner (CPO) and Principal Scrum Master (PSM). But the soul of the CIPSA framework is the CIPSA team as I’ve noted here. 

Without the developers, including the integrations specialists in the CIPSA team, there is no delivery. If there is no delivery, then Scrum at Scale has no real meaning, use, or purpose. 

In addition, there can be a Sponsor. Without a Sponsor or an executive champion, the product is not actively pursued or supported at the executive level. The Sponsor is not directly part of the CIPSA Scrum team but plays a crucial role.

In this article, I’ve taken four metaphors to describe the four roles used in the CIPSA Scrum Framework. CIPSA is world’s only framework that is practical and hands-on. These metaphors set the mindset, which is crucial for implementing the CIPSA framework.

Top 10 Reasons to go for the CIPSA Certification. See here.

Importance of Metaphors

Metaphors exist in every language, including English. In our context, they relate to Agile at Scale, specifically Scrum at Scale using the CIPSA framework.

In individual team-level Scrum, there are only a few people, roles, events (ceremonies), and artifacts. Complexity and dependencies are minimal, and risks, impediments, issues, and problems are mostly contained within the individual Scrum team.

However, Scrum at scale will be very different because of the followings:

• A number of teams will be involved and hence, a number of people.
• There have to be new roles.
• There will be meta-events, not events.
• Additional artifacts will be required. 
• The complexities, obviously, will be more. 
• The focus will be on inter-team risks and dependencies, among others.

Hence, the mindset to scale has to be different when compared to the mindset at individual team-level. To reiterate, metaphors play a crucial role in setting this mindset – the mindset of scale. 

The metaphors used in the CIPSA Scrum Framework are:

• Ninja,
• Guide,
• Mastermind, and
• Patron.

Now, let’s have a look at them briefly. The detailed elaboration is be part of the CIPSA certification course. See the details here.

Ninja

The developers in the CIPSA Scrum Team are Ninjas. A ninja is a top-class implementer. He or she is classically stealthy and highly skilled. Give a ninja a task, and be assured that the work will get done. There is no second-guessing here. This skilled executor focuses on delivering high-quality work and is not high dependent on others to deliver. The ninjas thrive on autonomy and mastery. 

It’s the ninjas who deliver the work and provide the CIPSA Integrated Increment every Sprint. See here.

Guide 

The guide is the Principal Scrum Master and is always available to the CIPSA team. The PSM helps CIPSA team members solve cross-team problems (issues and impediments), rejoices in the team’s growth, shares his/her knowledge, and offers experience. 

In addition, the guide champions Agile values and principles and ensures the team continuously improves. Some of the value and principles may or may not be applied at Scale, but it’s the job of the Guide to understand and provide solutions.

The guide, i.e., the PSM can also be called the coach of the entire CIPSA team. See here.

Mastermind

The mastermind is the Chief Product Owner. In this role, the mastermind is the chief strategist, thinking ahead about the items to be added to the Product Backlog. The CPO, as I’ve noted in this article (see here), is not a backlog maintenance person, but a backlog strategist. 

The mastermind is a visionary who steers product direction and backlog prioritization. As this person thinks ahead, hence the name or metaphor. 

Patron 

The Sponsor is the patron. The patron is the one who supports the product's delivery and remains continuously invested. This person secures resources and organizational support. The patron also champions the initiative at the executive level.

It’s the patron who secures the funding and brings in the resources – financial, assets, material, equipment or others. Hence, the metaphor!

Table Brief – Ninja, Guide, Mastermind and Patron 

Now that understand the metaphors used in the CIPSA Certification Course, it’s a good time to have a summary table. It’s shown below.

Live Video Explanation

I’ve prepared a video [duration - 09: 28s] to further consolidate your understanding. Watch the video alongside this article for a better learning experience. Don't forget to plug-in your headphones and go full-screen HD.

Conclusion

You now may be wondering are there any metaphors in the CIPSA Kanban Framework? 

Yes, indeed! There too we’ve metaphors, but they’re different from CIPSA Scrum Framework. Scrum and Kanban are not the same! Hence, when you scale, your thinking also has to be different. 

For example, in the CIPSA Kanban framework, I’ve used the metaphors of Samurai and Sensei to explain on my visualization of the roles. As wrote in the beginning, it helps to set the mindset when applying Agile at Scale.

So, whether you go for the CIPSA Scrum or Kanban frameworks for implementation in your teams and/or organizations, keep these metaphors and roles in mind to get the maximum value out of your CIPSA certification.

CIPSA Sample Videos:

[1] CIPSA Sample Video List (Choose a Video)

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Sample Questions:

[1] CIPSA Certification Sample Questions (Part - 1)

[2] CIPSA Certification Sample Questions (Part - 2)

CIPSA Certification:

[1] NEW Scaled Agile Certification Course: Certified In Practical Scaled Agile (CIPSA)

[2] Frequently Asked Questions (FAQs) - CIPSA Certification  

[3] New Practical Scaled Agile Framework – The CIPSA Framework Guide

[4] Understanding the CIPSA Scrum Framework – Practical, Hands-on Scrum at Scale

[5] The CIPSA Framework Clock - A Unique Way

Practical Scaled Agile (CIPSA) Certification: The Chief Product Owner (CPO) – What It Is and What It’s Not!

The CIPSA Framework introduces two primary roles for Agile at Scale: Chief Product Owner (CPO) and Principal Scrum Master (PSM) for Scrum or Principal Flow Master (PFM) for Kanban. The CPO role is new and not available in many scaled Agile approaches. However, it is one of the key roles and is crucial for product success. 

In this post, we will learn more on the CPO role as there can be misconceptions and misunderstandings. It’s presented in the form of what it is and what it is not, in order to have more clarity. Do note again, the CPO role applies both to Scrum at Scale and Kanban at Scale.

The following are some of them. To read all articles of this series use this link: What It's and What It's Not series for CIPSA.

Chief Product Owner – What It’s and What It’s Not

1. Not Delegated Vision, but Owned Vision: The Chief Product Owner does not get the product vision from the top executive team. The Chief Product Owner sets the product vision.

The CPO crafts a clear, compelling vision based on customer insights, market trends and business strategy linked to organizational strategy. The CPO leads the product direction and aligns stakeholders around a shared purpose (and goal), instead of relying on top-down directives.

2. Not Management Role, but Visionary Role: The Chief Product Owner is not a portfolio or program manager. The Chief Product Owner is the visionary for the Product.

Unlike a portfolio or program manager who focuses on scope, budgets and/or timelines, the CPO drives the “why” and “what” of the product at scale. The CPO envisions the product’s future and champion its value delivery across the organization.

3. Not Backlog Maintainer, but Backlog Strategist: The Chief Product Owner is not a backlog maintenance person. The Chief Product Owner is the main backlog strategist.

The product backlog, which is only one, is not a list to be managed. The CPO shapes the backlog as a strategic tool to maximize product outcomes and bring value. The CPO makes sure backlog items reflect the product vision, customer needs as well as business priorities. The product backlog is ordered.

4. Not Isolation, but Collaboration: The Chief Product Owner is not a lone-wolf. The Chief Product Owner works with other Team Product Owners, stakeholders and customers.

The Chief Product Owner thrives through collaboration, not isolation. He or she aligns multiple individual team product owners, gathers stakeholders' inputs and integrates customer feedback. Through cross-team communication, the CPO ensures a cohesive and value-driven product evolution.

5. Not Delivery, but Inspection: The Chief Product Owner does not manage the delivery of CIPSA Integrated Increment. The Chief Product Owner inspects whether the CIPSA Integrated Increment meets the CIPSA Goal. 

The CPO doesn’t oversee execution or delivery logistics. Rather, the CPO evaluates outcomes against strategic objectives of the organization. The CPO's focus is ensuring that what is delivered aligns with the overall Product Goal - hence the CPO inspects the CIPSA Integrated Increment. See here.

6. Not CIPSA Goal Ownership, but CIPSA Goal Alignment: The Chief Product Owner is not the owner of the CIPSA Goal. The Chief Product Owner ensures the CIPSA Goal is aligned with the Product Goal.

Unlike the Product Goal, for the CIPSA Goal, the CPO is not the owner. The CPO ensures that it contributes meaningfully to the overarching product goal/objectives. The CPO acts as a bridge here.

7. Not Management Mindset, but Ownership Mindset: The Chief Product Owner is not the manager of the product. The Chief Product Owner is the owner of the Product and has an ownership mindset.

The CPO role is not about task management or people management. Rather, the CPO takes full accountability for the product’s success. The CPO thinks long-term, acts proactively and leads with a deep sense of responsibility for product outcomes and success.

Summary Table – Chief Product Owner

The following table contrasts common misconceptions with the true nature of the CPO role, highlighting key differences in focus and approach. It's easy to remember and recall. The complete table and explanation are part of the CIPSA certification course.

Closing Remarks

It’s the CPO who first presents the refined Product Backlog to the CIPSA team in the CIPSA Planning meta-event. Only then does the actually planning start, leading to the work items that can be broken down into individual tasks, and finally, execution is done by the CIPSA team to deliver the CIPSA Integrated Increment. See here.

You can also read the unique article - two key roles and goals in CIPSA. See here.

The CPO is indispensable with his/her responsibilities for the success of the product by meeting the Product Goal and hence the Organizational Goals.

The above list of 'what it’s' and 'what it’s not' is a brief one. 

• Want to know in-depth about the CPO?
• Want to learn with hands-on, practical software tool?
• Want to see how the backlog items are prioritized? 
• Want to break down features in a hands-on manner?

Consider being a CIPSA professional. It’s worth every penny. 

CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not Series - CIPSA

CIPSA Sample Videos:

[1] CIPSA Sample Video List (Choose a Video)

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Sample Questions:

[1] CIPSA Certification Sample Questions (Part - 1)

[2] CIPSA Certification Sample Questions (Part - 2)

CIPSA Certification:

[1] NEW Scaled Agile Certification Course: Certified In Practical Scaled Agile (CIPSA)

[2] Frequently Asked Questions (FAQs) - CIPSA Certification  

[3] Scrum at Scale: CIPSA Key Roles and Goals with MS Project Agile

[4] Understanding the CIPSA Scrum Framework – Practical, Hands-on Scrum at Scale