CIPSA Cross-Team Backlog Refinement – Turning Scaled Agile Theory into Practical Execution

According to the CIPSA Framework Guide, one of the meta-events is the Cross-Team Backlog Refinement. The other meta-events, as noted in this article, are CIPSA Planning, CIPSA Daily Stand-ups, CIPSA Review and CIPSA Retrospective. While the CIPSA Sprint is the container event, the latter four are contained events.

However, the CIPSA Cross-Team Backlog Refinement meta-event is neither a container nor a contained event. Even so, this meta-event is essential, as emphasized in the CIPSA Framework Guide.

The guide is free to read and download. The download link is below:

Download the CIPSA Framework Guide

In this post, we will use CIPSA Scrum@Scale to demonstrate how this can be implemented in a practical manner using the MS Project Agile software tool.

Please note that the CIPSA framework supports both Scrum and Kanban at the team level. However, the content below specifically focuses on team-level Scrum scaled to manage multiple Scrum teams.

Basics of Cross-Team Backlog Refinement

As the name tells, in this session the backlog is refined. The backlog presented should be organized and up to date. The Chief Product Owner (CPO) should inform the CIPSA team in advance about the items to be ordered. This can be done by publicly publishing the backlog items for the CIPSA team. 

In every Sprint, the CIPSA team should allocate a few hours for refinement. During this meeting, the CIPSA Scrum Team and the Chief Product Owner (CPO) work together to carry out the refinement activities. Note that the CPO is part of the CIPSA team. 

The purpose of this meeting is to prioritize and order backlog items that may be taken into upcoming Sprints. We usually look ahead by two to three Sprints. The CIPSA team must maintain the discipline of continuously refining backlog items. 

Practical Backlog Refinement

The CIPSA Certification, based on the CIPSA Framework, is practical and hands-on. Therefore, we will now explore how to apply it in a practical, hands-on manner, including Backlog Refinement in our plan.

To include these events in your plan, we will follow just three steps. Note that this is not the only way to incorporate this meta-event; other approaches are also possible.

The steps are not difficult if you've understand how scaling works while using Scrum at team-level and how to apply it with MS Project Agile. 

Step – 1: Build the Product Backlog

The Product Backlog, once prepared, will appear as shown below in MS Project Agile. At this stage, the items are not yet ordered.

As demonstrated above:

• There are several backlog items such as “Login to the trading system”, “Create a new user”, and “Buy a stock”, which are currently unrefined. 
• The Team custom field indicates that these backlog items are not yet associated with any specific Scrum Team. 
• The Sprint built-in field shows that none of the unrefined backlog items have been assigned to a Sprint. 

Step – 2: Add the Backlog Refinement Meta-Event

Next, as the CIPSA Sprint Backlog is prepared, we will include the Backlog Refinement event in our plan. This is shown below.

As shown above:

• We now have an initial cut of the CIPSA Sprint Backlog, along with “Cross-Team Backlog Refinement 1”. 
• The Sprints are associated with the work items, but not with the Cross-Team Backlog Refinement item, since this meta-event occurs outside of the Sprint. 
• Some resources are overallocated, which will be resolved using the resource leveling functionality available in MS Project Agile. 

Step – 3: Repeat Backlog Refinement Meta-Event

I've noted earlier that the Cross-Team Backlog Refinement session occurs periodically and therefore needs to be repeated. This is shown below. 

As demonstrated above, the next Cross-Team Backlog Refinement (number 2) is scheduled to take place before the start of Sprint 2.

Note: These backlog refinement sessions can also be added as recurring events in your plan by using the Recurring Task functionality in MS Project. 

Conclusion

I've repeatedly observed that two events get skipped from Scrum at Team level:

• Retrospectives, and
• Backlog refinements.

The same behavior is also seen in Agile at Scale or Scrum at Scale. 

A CIPSA team is highly likely to skip this meeting, assuming that refinement will take place during CIPSA Sprint Planning. However, the purpose of the CIPSA Sprint Planning meta-event is entirely different! 

Some CIPSA teams miss this event and instead handle refinement in an ad-hoc manner, which is not advisable. Skipping the Cross-Team Backlog Refinement session is a significant misstep.

In every Sprint, the CIPSA team should allocate a few hours for refinement. After all, the Product Backlog is a prioritized and ordered list of items, and only the highest-priority items are selected for upcoming CIPSA Sprints.

Finally:

As we just learned, you can have the Cross-Team Backlog Refinement incorporated into your plan with minimal effort, provided you understand how to apply the theory in practice.

It's only with practical application that the rubber meets the road. And as you proceed, you burn the rubber to learn along the way. CIPSA teaches it for Agile@Scale.

The below explains more on the utility of CIPSA certification and why it shines in your resume.

When going for learning, practical, hands-on applicability is indispensable. CIPSA is radically different when compared with theoretical or "branded" certifications.

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

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

 

The CIPSA Sprint is the container meta-event in the CIPSA Scrum Framework. This meta-event will have multiple contained meta-events such as:

  - CIPSA Sprint Planning,

  - CIPSA Sprint Review,

  - CIPSA Sprint Retrospective, and

  - CIPSA Daily Scrum. 

In this article, we know more about a container meta-event, i.e., the CIPSA Sprint. There is another meta-event of CIPSA Cross-Team Backlog Refinement. However, it's not a contained meta-event. You learn more here. 

To reaffirm, CIPSA is world's only Practical Scaled-Agile certification. 

To read all articles of this series use the below link: 

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

Here are seven differentiators in the same format (it’s vs it’s not) for CIPSA Sprint. Exhaustive explanation is part of the CIPSA Certification Course. See here. 

Now, let's dive into this container meta-event.

The CIPSA Sprint Meta-Event – What It’s and What It’s Not

1. Not Isolated Team Cycles, but Synchronized CIPSA Team Cadence.

A CIPSA Sprint is not a separate sprint for each individual Scrum teams. But all teams sprint together with the same start and finish dates in a synchronized way. The CIPSA Sprint meta-event is the encompassing event for all other meta-events and it's the synchronized with the individual Team-level Sprints. 

Read this detailed article on the synchronization part. 

2. Not Independent Goals, but a Unified CIPSA Sprint Goal.

The CIPSA Sprint is not driven by individual team Sprint Goals, which will be part of the individual Team Sprint Backlogs. Rather, it’s driven by a single shared CIPSA Sprint Goal.

The CIPSA Sprint Goal is aligned with the Product Goal, which is part of the Product Backlog. To learn more, you can read this in-depth article.

3. Not Random Durations, but Consistent Timeboxes.

The CIPSA Sprint is not ad‑hoc or is of uneven duration. It’s a fixed timebox and is usually consistent duration across all teams. There is a reason we have Sprints in Scrum. The same rule applies for the CIPSA Scrum at Scale. 

4. Not Merely Team Task Execution, but Cross‑Team Coordination.

In the IPSA Sprint, it's not merely about individual teams’ execution. It establishes coordination points across teams for planning, reviews, and retrospectives. As stated earlier, the CIPSA Sprint is the container meta-event for other meta-events.

5. Not Individual Increments, but CIPSA Integrated Increment.

The result of a CIPSA Sprint is not fragmented increments coming from individual Scrum team. At the end of the CIPSA Sprint, we get a CIPSA Integrated Increment that is tested, integrated, and valuable.

Learn more on it with this article: CIPSA Integrated Increment - What It's and What It's Not!

6. Not only Local Backlog Work, but Product‑Goal Alignment.

A CIPSA Sprint is not focused on completing only team backlog tasks. Rather, it keeps alignment with the long‑term Product Goal through the CIPSA Sprint Goal. In every Sprint, the CIPSA team inches closer to the Product Goal.  

7. Not Siloed Team Scrum Boards, but Integrated CIPSA Team Board.

A CIPSA Sprint is a coordinated effort across teams to deliver value together. It is not separate scrum boards where teams never touch or coordinate dependencies. 

As you proceed with the CIPSA course, you’ll quickly know the tracking at the CIPSA team level is done with the integrated CIPSA Scrum Team Board. This board provides the integrated view for all individual Scrum teams. 

To know on Kanban at Scale board management, you can read this article. It's hands-on and practical. It has both - individual Team Kanban Boards and CIPSA Team Board. 

Summary Table – The CIPSA Sprint 

I’ve provided this summary table in conclusion. This is for a quick recap and understanding. 

In Conclusion

Want to know how a CIPSA Sprint is created?

Want to know how multiple CIPSA Sprints can be managed at scale?

Want to know how CIPSA Sprints will be associated with the CIPSA Team?

Want to know how to have contained meta-events with CIPSA Sprint?

Want to know how to synchronize multiple Sprints for the CIPSA team?

Detailed, hands-on explanations is part of the CIPSA certification course. Become a CIPSA – it’s truly worth the investment, as affirmed by CIPSAs worldwide. 

CIPSA Success Stories and Reviews:

[1] From CHAMP to CIPSA – Taking Agile to the Next Level with Scaled Scrum and Scaled Kanban

[2] Scaling Agile: Key Insights from the CIPSA Framework Introduction

CIPSA Sample Videos and Questions:

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

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Certification:

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

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

Portfolios, Programs and Projects – The NEW Definitions in PMBOK 8th Edition

In the value-delivery system of an organization, all 3 Ps – Portfolios, Programs, and Projects – are integral parts. Interestingly, the definitions of all three have changed in the latest PMI-PMBOK Guide, 8th edition. 

Put differently, in the future it will impact all – aspiring Portfolio Management Professionals (PfMP), Program Management Professionals (PgMP), Project Management Professionals (PMP), and Risk Management Professionals (RMP). Do note that the impact is not immediate, but in the future. 

Definitions are important because they create a clear and shared understanding. Without precise definitions, communication can become confusing or misleading, as people may interpret the same word in different ways. 

In management as in everyday contexts, definitions act as a foundation for learning, discussion, and critical thinking. They help us to organize knowledge, set boundaries for meaning, and ensure that our arguments or explanations are consistent, coherent, clear, and logical. 

In this article, we will explore these concepts in more detail. In organizations, initiatives typically begin at the portfolio level, so we will first examine the definition of a portfolio, followed by those of a program and a project.

Portfolio Definition

Earlier, we had the following definition:

A collection of projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives.

Now, the definition is significantly changed: 

A collection of programs, projects, and operations managed as a group to maximize overall value delivery and achieve strategic objectives, meet mandatory obligations, or generate income streams.

There are a few noticeable differences here:

1. Subsidiary portfolios are no longer mentioned, but in reality, it’ll be there!
2. Overall value maximization is emphasized explicitly.
3. Generation of income streams are introduced for the first time. 
4. In addition, it can be also about meeting mandatory obligations, e.g., legal, regulatory or others.

Above all, the continued focus on achieving strategic business objectives is there.  

The "generation of income streams" part is completely new. In fact, it has been added for the first time. In a portfolio context, an organization might run multiple initiatives that each create different income streams, so they’re not dependent on just one source of revenue.

Let’s take an example. You’re running a set of initiatives in a SaaS (software-as-a-service) start-up to get recurring revenue from software tools. These projects, within a portfolio, are not related, but can have some commonalities such as technology being used and hence, part of a portfolio. 

Program Definition

Earlier, we had the following definition:

A group of related projects, subsidiary programs, and program activities that are managed in a coordinated manner to obtain benefits not available from managing them individually.

Now the definition is changed to: 

A group of related projects and program activities managed in a coordinated manner to obtain benefits not available from managing them individually. 

Here we have one difference:

1. Subsidiary programs are no longer mentioned, but in reality, it’ll be there!

Programs are always about benefits and hence value. In addition, it's coordinated management of program components to deliver benefits. 

Program has a dedicated domain called Benefits Management, where we do benefits analysis, planning, delivery, transition, and finally, sustainment of benefits. The whole idea of having a program is to have coordinated work in order to deliver benefits/value to organization. 

Project Definition

Earlier the definition of the project was:

A temporary endeavor undertaken to create a unique product, service, or result.

Now the definition has changed and it is: 

A temporary initiative in a unique context undertaken to create value.

This is a real change of words here. The differences are:

1. No longer an endeavor, but an initiative.
2. Context has to be unique.

The initiative word confuses many. It need not be the case. 

As I've written here many times at ManagementYogi, an organization's strategic plan is subdivided into a set of organizational initiatives influenced by the market conditions, customer requests, or obligations etc. to be met. 

Next, a number of initiatives are grouped into a portfolio. In other words, a portfolio can contain proposals for various initiatives such as projects, programs, subportfolios, operations etc. It can also encompass already existing projects or programs within an organization. 

In that sense, the definition of a project is perfectly aligned with portfolio and its management. Because a project is indeed is an initiative within a portfolio. 

The other aspect is the uniqueness of context. It’s possible for two projects to involve constructing two identical buildings, but the context can still differ. For example, the location, technology, and resources may vary between these projects. Isn’t that right? 

The most important one is the final aspect of the definition – creation of value. Project is now about creating value by producing tangible and/or intangible deliverables. 

Figurative Representation 

The following figure outlines portfolios, programs, and projects in an organization.

                                 

As shown above, an organization’s vision, mission and strategic objectives are documented in the strategic plan. This plan is subdivided into a set of initiatives. Initiatives are then grouped into portfolios. 

Portfolios of programs and projects in an organization provide the value delivery system. And, as we just learned, all 3 Ps – Portfolios, Programs and Projects – are about creation, enablement and/or maximization of value delivery.

Conclusion

If you've followed my books and/or used my courses, you'll know that I say the following:

Project creates and delivers. Programs coordinates and guides. Portfolio decides and drives.

For more details, check out this article and also Part 2.

By now, you would have noticed that a shift has occurred across all three Ps toward value delivery. I'll change it from the value delivery perspective. 

Project creates and delivers value. Program coordinates to obtain benefits and value. Portfolio maximizes overall value. 

I can also shorten it further and say:

👉 Project creates value. 

👉 Program coordinates benefits/value. 

👉 Portfolio maximizes overall value.

References:

[1] PfMP Live Lessons - Guaranteed Pass or Your Money Back, by ManagementYogi.com

[2] PMP Live Lessons - Guaranteed Pass or Your Money Back, by ManagementYogi.com

[3] RMP Live Lessons - Guaranteed Pass or Your Money Back, by ManagementYogi.com

What Does it Take to Be a PfMP? If it Were Easy, Everyone Would Do it!

Becoming a Portfolio Management Professional (PfMP) from the Project Management Institute (PMI) requires more than just passing an exam. It demands a strong understanding of portfolio management concepts, the right mindset, and consistent preparation. 

PfMP is PMI's highest-level certification. 

Unlike project or program management, portfolio management is strategic in nature and focuses on selecting and governing the right investments for an organization by choosing the right components in a timely manner. 

As I keep saying:

Projects create. Programs guide. Portfolios decide.

At the portfolio-level, you decide the components to take or drop, the investment to make or cancel, and of course, the strategic business objectives to be met.

Your success in the PfMP journey depends on how well you understand the underlying processes, apply concepts in real-world contexts, and prepare with disciplined practice. 

The following key points provides practical guidance to help you approach your PfMP preparation in a structured and effective way.

There are two assumptions: a) Your application has been approved following PMI's panel review. Management Yogi provides support for it. b) You've decided to prepare for and proceed with the PfMP exam.

The following ones are based on my interactions and experiences with certified PfMPs as well as enabling many professionals to become certified PfMPs over the years. 

--

1. Understand the flow of Portfolio Management processes.

In portfolio management, there are multiple process groups, processes as well as knowledge areas. It's easy to get lost with such vast content. 

This is where understanding the flow of processes becomes important. The flow helps you build a mind map and clearly presents the big picture in a narrative way. When you prepare in this manner, you gain a clear understanding of what portfolio management, as illustrated by PMI, is all about.

Most providers of PfMP courses don’t understand this flow, but it is very important. 

2. Learn with hands-on tools whenever you can.

Portfolio management is fundamentally different from program or project management. You need to learn it with a different mindset. 

Using software tools such as Primavera or MS Project adds clarity. With just theory, achieving that clarity is difficult.

In addition, there will be plethora of tools and techniques (T&Ts). Software tools will help you tackle these T&Ts.

3. Use high-quality questions.

In your PfMP exam, questions will be of a high standard. They are situational in nature and will ask what to do next, what you should do, or even, what you should not do! Rote learning will not help. You must understand the concepts.

You can expect confusing, puzzle-like questions. Sometimes they can be frustrating – for example, all choices may seem valid, or the question itself may not be very clear. 

Don’t expect the questions to be grammatically perfect or linearly structured. They are designed to challenge you. They are not testing your grammar or linear thinking, but these:

• Are you truly suitable to be a portfolio manager?
• Can you apply portfolio management concepts in the real-world?
• Are you psychologically prepared to grasp and apply these concepts?
• Can you apply various portfolio management tools and techniques?

These insights come from high-quality questions. If you want low-quality ones, the internet is full of them. Everyone claims to be an expert on the web, but reality is different.

4. Always remind yourself: "There is no shortcut. I've to work for it."

You must truly work hard to become a PfMP. As the saying goes: 

On the highway to success, there are no shortcuts. 

You not only need the required portfolio management and business experience, but also sincere preparation. 

If you expect a magic wand or quick tricks to succeed in days or weeks, you will be disappointed. Again remember, there are no shortcuts. 

5. Choose a truly good and simplified course.

Your chosen course must be good, understandable, and digestible. Because portfolio management is vast, it’ll take time to digest. With the right course, your learning will be effective. Of course, real-world portfolio management experience is also important. 

Online learning is preferred because:

• You can access it anytime, from anywhere in the world.
• You can revise as many times as you want. You can also focus on areas where you are weak or not scoring well.
• You can learn at your own pace without feeling rushed or held back.
• It is usually more cost-effective, saving on travel, food, and accommodation.
• The duration is longer compared to classrooms. You can balance learning with your professional and personal commitments.

With a good mentor, you can ask questions and get them clarified.

The course creator or your PfMP coach plays a significant role in your journey. 

6. Practice, practice and practice.

The old saying “practice makes perfect” is true. The more you practice, the better and more confident you become. This complements the previous one, i.e., a good course.

The tools, techniques, content, explanations should be top-notch and high-quality. Practicing with high-quality material gives you the best value. You’ll also remember more when you practice more. 

7. Have a different mindset – the strategic mindset.

Portfolio management is strategic in nature, whereas program and project management are usually tactical. Portfolios focus on choosing the right work, while projects and programs focus on doing the work right. 

Selecting the right work for an organization is inherently strategic.

Projects and programs deal with execution, whereas portfolio management is more business-oriented. This is where key investment decisions are made. Hence, while going for the PfMP, you need to have a strategic mindset. 

8. All domains are important: Strategic, Governance, Performance, Communication, and Risk.

Your PfMP exam is based on the Examination Content Outline (ECO), not strictly on PMI books, references, or standards. 

The ECO provides the blueprint for the exam.

Unfortunately, many courses follow their own templates without mapping to the ECO domains or tasks. If you prepare this way, you risk failing the exam. 

9. Stay in touch with your coach. 

Throughout your preparation, your coach – most likely the course creator – will be extremely important. He or she will motivate, inspire, and guide you. 

In addition, as I've seen, when you stay in touch, you are more likely to prepare consistently with patience and in the end, it works out better for you.

Some may charge high fees but won’t provide proper support or guidance. In such cases, success becomes difficult. Many also don’t know the exact content needed to be a PfMP!

Your determination matters greatly and there is no substitute for it. Consistent support is also important. 

10. Never give-up.

Success is not final and failure is not permanent. Life itself is a continuous learning process. We learn every day until the end. 

When you understand this, giving up is not an option.

Becoming a PfMP is not easy, and as the tile of this article goes – if it were easy, everyone would do it.

You've a dream to be a PfMP. Pursue that dream. Dreams do come true and many have become PfMP with my PfMP courses and/or PfMP book. Check out few of the PfMP SUCCESS STORIES.

--

There are very few PfMPs in the world, unlike PMPs, which have around 1.5 million certified professionals. In comparison, the number of PfMPs is significantly lower. In fact, it’s not even 1% of the number of PMPs! Yes, not even 1%!

You can now understand the significance of the PfMP certification. There are tens of millions of project professionals worldwide. Only a small fraction pursue the PMP certification. 

Hence, achieving the PfMP places you among the top 1% of the top 1% within PMI’s PPP certifications and gives a boost to your career. It also serves as a strong differentiator in your profile and resume.

ManagementYogi’s PfMP courses have a proven track record, with many candidates successfully becoming PfMP certified. Some even achieve this without holding a single PMI certification beforehand!

These courses and books will help you understand, learn, and apply the required concepts and ultimately become a certified PfMP.

PfMP Exam Courses and Book:

[1] PfMP Live Lessons - Guaranteed Pass or Your Money Back, by ManagementYogi.com

[2] PfMP Exam Prep Online Course with Money-Back Guarantee, by ManagementYogi.com

[3] PfMP Exam Prep Book – I Want To Be A PfMP, First Edition, by Satya Narayan Dash, CIPSA, CHAMP

Program Change Request Management (PgMP) and Flow – The Standard for Program Management

Change is inevitable in every walk of our lives. Project, program, and portfolio management (PPP) are no different. However, the way changes are handled will differ in respective P-P-P management. 

Projects handle change with respect to the baseline and success is typically measured in terms meeting various constraints such as scope, schedule, cost, quality etc. Programs, on the other hands, takes a group of interrelated projects (and/or subprograms) to deliver benefits, which is otherwise not possible if you manage them individually. Hence, the program success is mainly about delivering benefits coming from outcomes of a program's components. Programs accept and adapt to change to optimize delivery of benefits. For portfolios – in sharp contrast – it's fundamentally about managing strategic changes.

Hence, I keep on saying in my interactions with Program Managers:

Projects are agents of change. Programs are coordinators of change. Portfolios are strategists of change. 

In this case, I'll focus on Program Change Management, which is key topic to know for aspiring Program Management Professionals (PgMPs) from Project Management Institute (PMI). 

For PMP change management flow, refer to this article. It’s one of the most-read articles. To understand deeply with lots of visuals and exercises, refer to the Guaranteed PMP course.

For PfMP change management, refer to this course: PfMP Live Lessons – Guaranteed Pass, which goes deeper into the strategic change management.

Note: There is no concept of processes or knowledge areas in PMI's Program Management Standard (SPgM). Rather we have various supporting activities and of course, the core activity of Program Integration Management. 

Program Management is much complex compared to Project Management as it’ll have a number of interrelated components driven together to deliver benefits. Hence, it’s best to simplify in understanding Change Request management for programs. The simplified flow diagram is shown below.

10 Key Points to Understand Program Change Request Management and Flow

Here are the 10 key points about program change request management. The reference for it taken from the Standard for Program Management from PMI.

1. A Program Change Request (PgCR) is a formal proposal to modify any program document, deliverable, or baseline. A PgCR can be a corrective action, preventive action or an update to program-level document.
2. During program formulation, we have the change assessment in the Program Change Assessment activity (shown above). The output of this activity is the Program Change Assessment. It happens with other assessments related to scope, schedule, financial, information, risk, quality etc.
   This helps in preparation of the Program Charter (PgC), which in turn enables the preparation of the Program Management Plan (PgMP).
3. Our next activity is the Program Change Management Planning activity (shown above) in the Program Definition phase. Here we create the Program Change Management Plan (PgCMP). It's a subsidiary plan of the PgMP. 
4. The Program Change Thresholds are also decided in the above-mentioned planning activity. The thresholds inform the level of change thresholds that should trigger the change process. For example, above 10% budget impact will be handled at the program level. 
5. The Program Change Management Plan (PgCMP) has the approach for capturing the change requests, evaluating each change, determining how to dispose the change, and communicating the decisions to the (impacted) stakeholders. 
6. The PgCMP is then fed into the next activity, i.e., the Program Change Management activity (shown above). It has both executing and monitoring & controlling aspects. This activity belongs to the Program Delivery Phase of the Program Life Cycle. 
7. All Change Requests are logged in a program-level document called Program Change Log. This log is created during the Program Delivery Phase and it’s created with the Program Change Management activity.  
8. The Program Steering Committee (also known as Program Governance Board) decides to approve or reject a requested change. Whatever may be the decision, it's recorded in the Program Change Log and the decision is communicated. Program Change Control ensures it. 
9. The PgCR, if approved after urgency and impact analysis, is called Approved Change Request (Approved CR). The approved CR is then implemented. Implementation can result in updates to subsidiary plans of the PgMP. 
10. The Change Decisions are always in the accordance with the Program Governance.
    The Program Governance Board or an appropriate body is responsible for defining the types of changes that a program manager can independently authorize/approve or that would require further discussion prior to approval.

--

The three key activities in Program Change Management cleanly maps into the various phases of the Program Life Cycle. It's shown in the below table.

That’s it! 

Was it difficult to understand? I believe it’s not. 

Again, do note that I’ve highly simplified the concept of program change management. As you go deeper, you’ll find many aspects to program change management. 

Nevertheless, simple things are always easier to remember, recall, and apply. 

Finally, as I close, I'll say this:

For projects, it's about integrated change control. 

For programs, it's about program governance and coordinated change control. 

For portfolios, it's about portfolio governance and strategic change management. 

Change Management:

[1] Change Request Flow (PMP) - PMBOK Guide 

[2] PfMP Live Lessons - Guaranteed Pass or Your Money Back

[3] PMP Live Lessons - Guaranteed Pass or Your Money Back

The Practical Scaling Imperative: 10 Lessons for An Aspiring CIPSA

 

The Certified in Practical Scaled Agile (CIPSA) framework helps professionals navigate scaling complexity by providing principle-driven, hands-on guidance for multi-team delivery. 

Based on the experiences of professionals who have taken the CIPSA course, the following lessons highlight the imperatives, mindset, and practices every aspiring CIPSA must embrace to succeed in real-world scaled Agile delivery.

I interact with them frequently and keenly listen to them. And I learn from them. 

Following are some of the lessons for aspiring CIPSAs.

--

1. Never, ever and under no circumstances think only at the team level.

A CIPSA must always see the bigger team, i.e., the CIPSA team, at scale. It is not about the individual Scrum or Kanban teams. To know more on CIPSA team, see here.

Scaled delivery succeeds only when teams understand how their work contributes to the larger product outcome. Thinking only at the team level leads to local optimization, local efficiency, but global ineffectiveness and inefficiency.

2. Never, ever and under no circumstances learn scaling without hands-on approach and software tools.

There is a plethora of Scaled Agile approaches, worldwide. However, not one – I repeat, not even one – tells how to do scaling in a practical, hands-on manner.

Nobody has truly learned anything by reading theoretical content. To learn, you have to do it hands-on. Agility scales through practice, not theory. 

You don’t scale by adopting a framework. You scale by doing the work. 

3. Never, ever and under no circumstances maintain multiple product backlogs for the same product.

One product demands one backlog. Vision at any time is only one and it’s part of the backlog. Multiple Scrum or Kanban teams under the CIPSA Team must move toward one shared vision. 

When teams maintain separate backlogs at the product level, priorities diverge, coordination collapses, and above all, nothing can really get accomplished. The single backlog ensures that all teams pull from the same prioritized source of work.

However, do note that there can be individual team backlogs. All these team backlogs will constitute the CIPSA Backlog – be it CIPSA Sprint Backlog (see here) or CIPSA Kanban Backlog (see here). 

4. Never, ever and under no circumstances ignore cross-team dependencies.

Dependencies are inevitable in scaled environments. In fact, you, as the Principal Scrum Master or Chief Product Owner, must know these dependencies. 

The responsibility of a CIPSA is to identify, visualize, and manage them proactively. Hidden dependencies often become the biggest delivery risks and stifle the delivery of CIPSA Integrated Increment (see here). 

5. Never, ever and under no circumstances refine work (backlog refinement) in isolation.

Backlog refinement in a scaled environment must involve multiple teams when work overlaps. It’s a dedicated meta-event for the CIPSA team and happens periodically. Without this event, the CIPSA Backlog can’t be properly prepared in the CIPSA Planning meta-event. 

Collaborative refinement ensures that teams understand upcoming work, dependencies, and integration points.

6. Never, ever and under no circumstances allow events to happen without synchronization. 

Scaled Agile delivery depends on synchronized events, e.g., in CIPSA Scaled Scrum, the Sprints are synchronized across teams. See here for an in-depth understanding on Sprint synchronization for multiple-teams. 

With it, all teams stay aligned and dependencies are managed effectively. Even if individual teams are performing well, lack of synchronization can cause misalignment, delays, and integration issues. Under no circumstance should a CIPSA allow teams to operate their events in silos when their work contributes to a shared product increment.

7. Never, ever and under no circumstances deliver work that cannot be integrated or cannot deliver an Integrated Increment. 

The purpose of scaling Agile is not parallel development. It’s about integrated delivery. The end goal in every Sprint or Release is to have a CIPSA Integrated Increment. 

You, as a CIPSA or an aspiring one, must ensure that increments from multiple teams combine into a cohesive product increment. See here for CIPSA Integrated Increment. 

8. Never, ever and under no circumstances allow lack of transparency across teams.

Visibility is the lifeblood of scaled agility. CIPSA team-level metrics should be shared clearly. Dashboard should be visible to all. Progress tracking to be on information radiators and entire team should be able to see it. 

This ensures transparency for all team members and stakeholders.

9. Never, ever and under no circumstances avoid CIPSA retrospectives.

The CIPSA framework has meta-events such as CIPSA Planning, CIPSA Retrospectives etc. I’ve consistently maintained that retrospectives and follow-up actions based on these retrospectives are of paramount importance. See here on the importance of retrospective. 

Some of the most critical improvements lie between teams rather than within the teams. Cross-team retrospectives help address systemic issues affecting collaboration, coordination, and flow – the latter in CIPSA Scaled Kanban. See here.

In fact, in the early stages of scaling, it’s CIPSA retrospectives that will bring the most value to your team. 

10. Never, ever and under no circumstances choose a “branded” framework over practical result.

The philosophy behind CIPSA emphasizes practical implementation. It’s a framework with ample guidance on how to proceed with hands-on software tools and scaling. 

Thorough explanation has been given on the implementation part taking real-world projects. This enables you to learn in the most effective way. 

What good is a “brand” if you can’t apply your learning in a hands-on manner from Day-1?

What good is a “brand” if you’ve paid loads of money, but have no real-world, practical use?

--

In conclusion, I’ll say the following. 

Many organizations proudly claim they have “Scaled Agile” and doing “Agile Transformation,” yet what they often have is a collection of independent Agile teams moving in different directions in Brownian motion. 

I’ve asked many Scaled Agile Practitioners who have been certified on “branded frameworks”:

• Can you show me a Scaled Backlog?
• Can you show the cross-team dependencies in a Scaled Agile Team?
• Can you show how you add the Meta-Events and how to track them?
• Can you create an integrated Burn-down/up chart for the entire team?
• Can you demonstrate how to allocate scarce, yet critical resources and resolve overallocations?
• And many more practical ones.

They don’t know and can’t demonstrate. And it’s certainly not their fault. 

They’ve just got a “branded certification” to show to their employers. They’ve flocked to it due to end-less marketing, promos and sometimes even film-actors parroting it! But it has no real-life value, no practical use other than “some branded tags”.  

Some believe that simply adding more Scrum or Kanban teams automatically leads to scalable delivery. It does not! Some others assume that coordination will somehow emerge organically once teams adopt Agile practices. The ground reality is far different and harsher. 

My experience in multi-team Agile environments in early last decade, learning from professionals who use my courses over the years, and above all the professionals pursuing the Certified In Practical Scaled Agile (CIPSA) course teach me the following:

True learning, implementation, and delivery happen in a practical, hands-on manner. No other methods come close. The best companies in the world understand this and ask their engineers to do it hands-on from the very beginning. 

If you are serious about understanding how Agile truly works at scale, there is no better way to learn than by immersing yourself in the CIPSA course.

👉 [Enroll Today] Pay via PayPal/Bank transfer. Email: managementyogi@gmail.com. Enroll in 24hrs.

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

Practical Scaled Agile (CIPSA) Certification: CIPSA Cross-Team Backlog Refinement – What It Is and What It Is Not!

There are meta-events in the CIPSA Framework such as:

• CIPSA Planning,
• CIPSA Daily Stand-ups
• CIPSA Review
• CIPSA Retrospective, among others.

One of the meta-events which usually gets overlooked is the CIPSA Cross-Team Backlog Refinement. 

It’s an ongoing activity for the CIPSA Team. In this article, we will know more on it.

The content of this article is based on the CIPSA 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 at Scale and Kanban at Scale.

To read all articles of this series use the below link: 

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

CIPSA Cross-Team Backlog Refinement – What It’s and What It’s Not

Among many, the following are some of the top ones. Detailed explanations with practical, hands-on demonstration using real-world projects is part of the certification course.

1. Not Team Specific, but Cross-Team Effort: The Backlog Refinement is not limited to a single team working on its own backlog items, but it's a cross-team effort. 

Representatives from multiple Scrum or Kanban teams who share the same Product Backlog will be participating in this meta-event. This cross-team collaboration meta-event helps ensure that different perspectives are considered, dependencies are identified early, and the upcoming work is understood.

2. Not Optional, but Mandatory: Backlog refinement is not an optional one, but it's mandatory for the CIPSA Team. 

Backlog refinement in the CIPSA context is not an optional or occasional activity that teams perform only when they feel the need. It is an essential meta-event that ensures the Product Backlog remains clear, relevant, and ready for planning. 

Without this refinement, planning sessions may become inefficient due to unclear requirements, missing details, or unresolved dependencies. Do note that the CIPSA Planning meta-event usually happens after backlog refinement. 

3. Not One-time, but Ongoing: The refinement session is not one-time session, but it's an ongoing one throughout the life of the product/service delivery. 

The backlog is not a static list that remains unchanged until planning begins. Instead, it evolves continuously as new information emerges, feedback is gathered, and priorities shift. The CIPSA Backlog Refinement meta-event reflects this dynamic nature - clarify, adjust, reorder, or even remove as needed.

4. Not Isolated, but Aligned: The refinement session is not done in isolation, but it's in alignment with the organization's strategic goals and objectives.

Backlog refinement does not happen in isolation from the broader product strategy and/or organizational goals. Rather, it ensures that the backlog items remain aligned with the product vision, which is in turn is alignment with strategic priorities of your organization. 

5. Not CIPSA Planning, but a Prep for CIPSA Planning: The Cross-team backlog refinement meta-event doesn't replace the CIPSA Planning meta-event, but in a way complements it.

CIPSA Backlog Refinement should not be confused with the CIPSA Planning meta-event itself. Its role is to prepare backlog items so that planning can be effective and focused. It clarifies scope, identifies inter-team dependencies, and ensures readiness beforehand.

6. Not a Commitment Session, but a Forecasting Tool: This meta-event is not a commitment session for the CIPSA team members, but it's a forecasting tool.

The purpose of backlog refinement is not to commit teams to delivering specific items. Instead, it helps create a realistic forecast of what work might be feasible in upcoming Sprints – as in CIPSA Scaled Scrum (see here), or Releases – as in CIPSA Scaled Kanban (see here).  

CIPSA Cross-Team Backlog Refinement – Summary Table

The summary table is shown below. The complete table is part of the CIPSA certification course.

Conclusion

I believe this post will bring a lot of clarity with respect to the Cross-Team Backlog Refinement meta-event. 

The CIPSA certification, based on the CIPSA framework, focuses on practical scaling with hands-on software tools. The CIPSA certification course has a 70%:30% ratio – 70% practical and 30% theoretical. As a matter of fact, it's world's only Practical Scaled Agile certification. 

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

--

CIPSA Success Stories and Reviews:

[1] From CHAMP to CIPSA – Taking Agile to the Next Level with Scaled Scrum and Scaled Kanban

[2] Scaling Agile: Key Insights from the CIPSA Framework Introduction

CIPSA Sample Videos and Questions:

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

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Certification:

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

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

The Hybrid Imperative: 10 Lessons for an Aspiring CHAMP

Hybrid-Agile management is complex, unlike traditional waterfall or pure Agile. The latter has been accepted and used in various industry verticals, but not all projects fall into either of these camps. A number of projects demand different approaches. 

As many professionals and practitioners use the Certified Hybrid-Agile Master Professional (CHAMP) course, and I listen to them; I also learn a number of things from them. 

So, what are the lessons can we draw from them? Here they are.

--

1. Never, ever and under no circumstances should you learn Hybrid-Agile without hands-on learning and hands-on software tools. 

Theory without knowing how to apply theory is effectively useless. Nobody has learned swimming, cycling, or driving by reading theoretical content.

You’ve to get your hands dirty. You may fail a few times, or many times; but then that’s how you learn. That’s why it’s known as the best form of learning. It teaches you the most. Software tools such as MS Project are heavily used in the CHAMP course for this purpose. In fact, it's 80% practical. See here.

2. Never, ever and under no circumstances, believe that one methodology fits all projects.

Pure Agile and pure Waterfall are frameworks, not religions to follow. The moment you treat one framework as universal, immutable and dogmatic; you lose the flexibility that Hybrid approaches bring.

3. Never, ever and under no circumstances should you abandon structure in the name of agility.

Sprints without right long-term planning become chaotic in the long run. Scrum projects also need governance. Because flexibility without direction becomes an endless drift. I’ve seen many such teams working in that mode. 

Hybrid means disciplined adaptability, not improvisation without accountability.

4. Never, ever and under no circumstances should you freeze requirements in a changing environment.

Markets evolve, stakeholders rethink, risks materialize, team members leave, technologies change. A Hybrid leader plans firmly, but revises the plan when evidences are there. You, as a leader in hybrid-agile environments, should never freeze requirements completely. 

This is because some parts of the projects will have churns. And that’s reason to use Hybrid in the first place! 

5. Never, ever and under no circumstances should you measure performance using only one lens.

In Agile/Scrum, there will be Burndown/Burnup charts. There will be Release Histograms. But they can hide technical risks. On the other hand, in Traditional/Waterfall, Gantt Charts can hide flow issues in the team. 

Hybrid management demands both predictive metrics and adaptive indicators. In fact, with MS Project software tool, you can have board views both predictive and adaptive parts. This is applicable for all: Hybrid-Scrum, Hybrid-Kanban, or Hybrid-ScrumBan. 

See here for Hybrid-ScrumBan. It's an in-depth, hands-on article. 

6. Never, ever and under no circumstances should teams operate without transparency.

As is the case with monetary debt, technical debt too multiply. People take huge monetary debt to lead rich lives only to realize much later debt truly accumulates. If you don’t pay it off fast, it’ll be exponential in nature. Technical debt is similar! 

It happens to many teams. Hence, your boards should be visible to all. Milestones should be clearly noted. Reporting must be honest. 

Transparency is one of the foundations of trust. Trust is the foundation of leadership. See here. Hybrid-Agile management is no different. 

7. Never, ever and under no circumstances should you confuse speed with progress.

Speed is not a good indicator of progress. Progress can be time-consuming and at times very frustrating – but it’s much more important than speed. In many parts of your Hybrid projects, speed can be less, but there will be progress. 

These can be seen with progress indicators as CHAMP shows. The MS Project software tool indeed has indicator columns, which can be color-customized.

8. Never, ever and under no circumstances should teams be organized in silos while expecting cross-functional outcomes.

In one of the principles of Hybrid-Agile management, I informed about frequent integration. Specifically, it’s Principle – 7. See here. 

Hybrid success requires integrated collaboration and integration between predictive and adaptive parts. Integration doesn’t happen on the final day or last few days/weeks of project completion. It happens frequently. This removes silos and truly improves collaboration. 

9. Never, ever and under no circumstances should planning be treated as a one-time ceremony.

In traditional approaches, the well-known saying is planning is indispensable, but plans are useless. And as we know, irrespective of that, we do plan as it’s essential. 

However, plans must breathe and the planning documents should be living documents. Hybrid planning is continuous. For example, there can be strategic quarterly alignment combined with tactical Sprint refinement sessions.

10. Never, ever and under no circumstances should you forget that Hybrid is about outcomes and value, not frameworks.

Ceremonies, artifacts, and roles matter less than delivering value on time. At the end of the day, it’s value – coming from the outcomes, capabilities, and benefits – to the customer what actually matters. 

Hybrid-Agile management is about that value and its delivery in the best possible way to the customers. 

--

Finally, I'll conclude with the following. 

Many organizations either worship Agile as a miracle cure or cling to Waterfall as a symbol of tradition, power and control. Some believe flexibility means freedom from discipline. Some others believe structure means protection from uncertainty.

But in many scenarios, as we’ve learned in the previous article (see here), they may not work at either end of the delivery spectrum – be it Adaptive or Predictive. 

As a management practitioners and a keen learner, you'd know that it's not a matter of superiority, but maturity – the maturity in knowing that they are different ways to deliver, depending on the type of project. 

My experience in Hybrid-Projects, learning from professionals who use my courses, and above all the CHAMP certified professionals teach me the following:

Hybrid-Agile management with CHAMP is not a compromise between two camps – Agile and Waterfall – but, a deliberate, thoughtful and principle driven approach to go with both predictability and adaptability. 

If you are serious about knowing Hybrid-Agile management, there is no better way to know than using the CHAMP course. Start today and get into a deep-dive mode. 

Hybrid is no longer optional – it’s the reality of modern project delivery. The future belongs to hybrid-ready leaders.

ManagementYogi's CHAMP Certification Course:

• Certified Hybrid-Agile Master Professional (CHAMP)

CHAMP Reviews and Success Stories:

• CHAMP Course: Excellent One for Mastering MS Project in both Traditional and Agile Environments
• CHAMP Success Story: A Niche Certification –Never Seen Anything Like this Before!
• CHAMP Success Story: One of the Best Hybrid-Agile Certification Courses I Ever Attended

Free CHAMP Questions:

• 20 CHAMP Free Questions with Answers (Part - 1)
• 20 CHAMP Free Questions with Answers (Part - 2)

Tips for Hybrid-Agile Management:

• 5 Tips for Hybrid-Agile Management
• 5 More Tips for Hybrid-Agile Management

Seven Principles of Hybrid-Agile Management:

• Seven Principles of Hybrid-Agile Management (Part - 1)
• Seven Principles of Hybrid-Agile Management (Part - 2)