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 suggests, 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.

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
• 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