Scrum at Scale: Product Backlog, CIPSA Sprint Backlog and Team Sprint Backlog with MS Project Agile

Even with a number of Scaled Agile frameworks, even with a number of courses on scaling Scrum teams, even with many experienced professionals getting certified year after year, when I ask Scaled Agile practitioners to differentiate between the backlogs at a higher-level to the lower team-level and how it's done, they fail. They can’t demonstrate. And I’ve asked many.

The reason is not hard to fathom. It’s not their fault. Rather, it’s due to lack of practical applicability. In other words, they’ve not seen it in action or used any good (software) tool. Hence, there is no real understanding and internalization, except knowing some theoretical jargon here and there. 

Scaling is complex, but it need not be complex to understand. As I write, the below age-old saying rings true:

I hear and I forget. I see and I remember. I do and I understand.

In this article, we will follow the above wisdom. We will learn by visualizing and applying. We will learn by doing. We will learn by going from the Product Backlog to CIPSA Sprint Backlog, which will be executed by the whole team. Then we will also visualize and learn the individual Team Sprint Backlogs. Towards the end, we will see all of these backlogs fit together in action in a video demonstration.  

So, let’s start with our current scenario. Exhaustive details are part of the CIPSA course. See here.

Our Scaled Scrum Scenario  

For our Scaled Scrum project using the CIPSA framework, we have three Scrum teams working together on a single product backlog. The three individual Scrum teams have various usual roles such as Developers, Scrum Masters and Product Owners. 

For the CIPSA team, however, we have two primary roles: 

Chief Product Owner (CPO), and Principal Scrum Master (PSM).  

To know more, see here for CPO and here for CSM.

These are unique roles for the CIPSA team and it’s shown in the below figure.  

The CIPSA team encompasses all the individual Scrum teams and has the above additional two primary roles. The CIPSA team is shown in the bigger circle, whereas the individual Scrum teams are in smaller circles within the bigger one. Also note that both the CIPSA team and individual Scrum teams are in Sprint 1, i.e., the Sprints are synchronized.

Proceeding further, for our case, we are going to follow the CIPSA Scrum Framework. You can download the CIPSA Framework for free here. 

Product Backlog to CIPSA Sprint Backlog to Team Sprint Backlog

The Product Backlog is for the entire CIPSA team. It’s a single one and has all the work items. The Product Backlog will have the Product Goal (see here) and a refined backlog will be presented to the CIPSA team in the CIPSA Sprint Planning meta-event by the CPO.

In this CIPSA Sprint Planning meeting, the CIPSA team will create the CIPSA Sprint Backlog, which will have the CIPSA Sprint Goal. 

Post this meeting, the individual Scrum teams will work on the items taken by them, break the items into individual tasks and create the respective Team Backlogs. In other words, for every Scrum team, we will have an individual Team Sprint Backlog. As we have three Scrum teams, we will have three Team Sprint Backlogs:

• Team A Sprint Backlog, 
• Team B Sprint Backlog, and
• Team C Sprint Backlog.

For your visualization, it’s shown in the below figure. 

As shown above, the Team Sprint Backlog is created from the CIPSA Sprint Backlog and the later one is created from the Product Backlog. The Team Sprint Backlog has the Team Sprint Goal, which is in alignment with the CIPSA Sprint Goal. The CIPSA Sprint Goal, on the other hand, is in alignment with the Product Goal. 

At the end of every Sprint, an integrated increment is given, which is known as the CIPSA Integrated Increment (see here). And with every Sprint, the CIPSA team is moving closer towards the Product Goal. 

The Prioritized Product Backlog

As mentioned earlier, we have a single Product Backlog and the CIPSA team is going to deliver a large, complex Stock Trading system catering to millions of users, customers and paid subscribers. 

When put into the MS Project Agile, the Product Backlog comes as shown below. At this stage, we have an unrefined backlog.  

Also note that we have not associated teams with the backlog items. As the CIPSA team completes the Cross-Team Backlog Refinement session, the items will be ordered and the entire team will have a forward-looking plan for the next two or three Sprints. 

Post our backlog refinement, we have the following Product Backlog shown again in the Sprint Planning sheet view.  

As shown above, now the items are reordered. The teams as well as the Sprints are now associated with the backlog items. For example:

• “Login to the trading system” is associated with Team A, whereas “Create a new user” and “Buy a stock” are associated with Team B and C, respectively. 
• All three teams are also associated with the upcoming Sprint, i.e., Sprint 1. 
• Similarly, some of the items are associated with Sprint 2 and Sprint 3. Such planning is known as rolling wave planning in Agile.

This can also be seen in the Sprint Planning Board view as shown below. 

After reordering the items, one can drag and drop items into the respective Sprints in the Sprint Planning Board, which is for the entire CIPSA team.

The CIPSA Sprint Backlog

Next, we are going to build the CIPSA Sprint Backlog. The CIPSA Sprint Backlog will have the following meta-events. 

• CIPSA Sprint Planning,
• CIPSA Daily Scrum,
• CIPSA Sprint Review, and
• CIPSA Sprint Retrospective.

These meta-events will be conducted in the Sprint 1 for the entire team. Hence, we will use the respective naming conventions. For example, for Sprint 1:

• the planning meta-event will be CIPSA Sprint 1 Planning, 
• the daily stand-ups will be as CIPSA Daily Scrum (Sprint 1) 1, CIPSA Daily Scrum (Sprint 1) 2 …
• the review meta-event will be CIPSA Sprint 1 Review, and 
• the retro meta-event will be CIPSA Sprint 1 Retrospective.

The naming convention is quite important to understand as we will run with multiple Sprints – possibly hundreds of them. You’ve to give clear naming conventions to differentiate between teams and Sprints. Otherwise, with multiple Sprints and multiple Scrum teams, it’s easy to get lost in the plan! 

After we have the meta-events added, the first version of the CIPSA Sprint Backlog (specifically, the CIPSA Sprint 1 Backlog) is shown below. 

Let’s interpret the above figure shown in the Gantt Chart. Similar one will be available in the Sprint Planning Sheet view.

• The first meta-event is the CIPSA Sprint 1 Planning. It’s a line item.
• The next one is CIPSA Daily Scrum for Sprint 1 and it’s a recurring item.
• The last two meta-events are CIPSA Sprint 1 Review and CIPSA Sprint 1 Retrospective. Both of these are line items.
• While the CIPSA Sprint Backlog related items are associated with “All Team”, the individual Scrum team items are associated with the respective teams.

All these items related to the CIPSA Sprint 1 Backlog are highlighted in blue. Again, do note the naming conventions.

The Team Sprint Backlog

Next, we will proceed to create the Team Sprint Backlogs for all the Scrum teams. In this case and per the CIPSA Scrum Framework, we will have the following events:

• Team Sprint Planning,
• Daily Scrums for individual teams, and 
• Team Sprint Retrospective. 

Do note the CIPSA Sprint Review replaces the individual Team Sprint Review, because our focus is on the CIPSA Integrated Increment, not the individual Team Increments. 

These individual team events will be conducted in the Sprint 1 for the respective Scrum teams. Hence, we will use the respective naming conventions. For example, for Sprint 1:

• the planning event for Team A will be Team A Sprint 1 Planning, 
• the daily stand-ups will be as Team A Daily Scrum (Sprint 1) 1, Team A Daily Scrum (Sprint 1) 2 …, and 
• the retro event will be Team A Sprint 1 Retrospective.

Here too, the naming convention is quite important to understand and use. 

Once we have these events, the first-cut of the Team Sprint Backlogs will be prepared. The figure shown below is for Scrum Team A. 

As you can visualize in the above figure, for Team A:

• The first event is the Team A Sprint 1 Planning. It’s a line item.
• The next one is Team A Daily Scrum for Sprint 1 and it’s a recurring item.
• The last event is Team A Sprint 1 Retrospective and it’s a line item.

Next, we will break the work items taken from the Product Backlog for Team A and break it down to individual tasks. While the feature items can be in story points or in any other estimation, the tasks will be estimated in hours. 

For the “Login to the trading system” feature for Team A, we will have the following tasks:

• Design and develop,
• Implement UI,
• Prepare test plans,
• Execute test plans,
• Integration Work, and
• PO Review.

Do note that the Team Increment can come anytime during the Sprint 1, but it has to be integrated into the main branch (or line) in order to have the CIPSA Integrated Increment at the end of the Sprint. 

After we have these tasks items, the Team A Sprint 1 Backlog will look like the one shown below.  

As shown above, the Team A Sprint 1 Backlog encompasses all the items, including the events, which will be executed or conducted in Sprint 1. Similarly, we will have two more Team Backlogs – Team B Sprint 1 Backlog and Team C Sprint 1 Backlog.

Demonstration – Backlog Management at Scale

Now, it’s a good time to see what we have learned so far with the help of MS Project Agile software tool. To support this, I’ve the following video [duration: 6m approx.], the content of which is taken from the newly launched Certified In Practical Scaled Agile (CIPSA) course. For the best experience, you may want to go full-screen with HD mode and plug-in your earphones. 

Exercise – Comparison of the Backlogs

We have understood how these Backlogs are prepared and we also looked at them practically. Next, can you think what are the differences among these backlogs?

Below are the five areas – creation of the artifacts, goal associations, the content inside followed by the life cycle of the artifact and events. In these areas, you can attempt to list out the differences. 

The answer is explained in the below video [duration: 5m approx.]. While watching the videos, bring out your pencil and paper to learn better. 

Conclusion

Slightly modifying the initial quote we started with, a related one is the following:

Tell me and I forget, teach me and I may remember, involve me and I learn.

Indeed, we learn by doing. Because that is when we get truly involved. 

There are connections among our fingers, hands and brains. When we do it with our own hands and our fingers are involved, coordination happens among our fingers, eyes and brains. 

Visuals like figures and comparison tables coupled with practical, hands-on applicability are powerful. Because with that, we quickly grasp the explained concepts. And as we do it ourselves, it registers in our minds and memories for a long time. 

I believe with this article you now understand how to manage the backlog items taken from a cross-team refined Product Backlog, build the CIPSA Sprint Backlog and multiple Team Sprint Backlogs.

--

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

References

[1] NEW Certification Course: Certified In Practical Scaled Agile (CIPSA), by ManagementYogi.com 

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

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

Practical Hybrid-Agile (CHAMP) Certification: Various Shades of Grey for a CHAMP

The phrase "shades of grey" usually refers to situations that are not just black or white, right or wrong, left or right. Instead, they exist somewhere in between, where clarity is fuzzy, ambiguity is dominant, and absolutes don't really apply.

Hybrid is one such area. The predictive model of development relies on heavy upfront planning. In some cases, it's absolutely needed. At the other end of the development spectrum, we have adaptive, where there is very little detailed planning. The planning is mostly just-in-time (JIT) and usually happens before the iteration (as in Scrum) or when capacity is available (as in Kanban). 

Hybrid development sits in between: between predictive and adaptive. It takes elements of both and delivers.

Understanding this need, the CHAMP certification has been specifically developed when Hybrid-Agile (or simply Hybrid) works best. CHAMP certification is all about hybrid. This certification is valuable because:

• It blends rigid and flexible: Traditional Waterfall (predictive) is structured and sequential, while Agile (adaptive) is iterative and incremental. Hybrid-Agile? It weaves together the two. Hence, the term grey.
• It's tailored, not textbook: With CHAMP and hence Hybrid-Agile, the project team doesn't follow the book. Rather, the team builds its own strategy based on the project's needs. The decision-making is in the grey zone, where trade-offs are not optional but essential.
• It's highly practical with needed theory: The CHAMP certification is the world's only practical Hybrid-Agile certification. It’s also highly economical. See here.

Now, let's see the various Shades of Grey for Hybrid-Agile, as used in the CHAMP certification. Though there are many, I've highlighted a few. 

Shade of Grey # 1: Hybrid-Scrum

In the hybrid world, Hybrid-Scrum is not just about stand-ups and retrospectives. It's not about upfront planning, either. It’s about embedding agility (Scrum) into a predictive framework — or predictive elements into an otherwise Agile project. 

The CHAMP course teaches how to conduct Sprint Planning alongside Gantt charts; how to align features (or user stories) with a WBS; and how to hold Daily Scrums alongside routine meetings.

Shade of Grey # 2: Hybrid-Kanban

Scrum thrives on Sprints. Kanban thrives on flow. Hybrid-Kanban brings not only the flow, but also visualization with Kanban Boards, identification of work-in-progress (WIP) items, reporting with Cumulative Flow Diagrams, among other tools. 

CHAMP doesn't just teach you Hybrid-Kanban management — it teaches you how to work with any type of Hybrid-Kanban project. Like Hybrid-Scrum, real-world projects are used here as well.

Shade of Grey # 3: Hybrid-ScrumBan

This is greyer than the greys! ScrumBan combines both Scrum and Kanban. Hence the name. Hybrid-ScrumBan goes a step further by blending Waterfall, Scrum, and Kanban.

As you progress through the CHAMP certification course, the Hybrid-ScrumBan approach becomes a powerful tool in your strategic toolkit. But how?

As a CHAMP, you learn when to iterate and when to go with flow. In other words, Sprints where needed, flow where it's a must. And once again, you'll master this through real-world, scenario-driven projects.

Shade of Grey # 4: Baselining Hybrid-Projects

Ask any professional, including management, and they’ll know the value of a baseline in a project. In predictive projects, baselining is essential to track progress, identify variances, perform variance analysis, and generate subsequent reports. 

In Hybrid-Agile, baselining can still be applied because it includes predictive elements. But how do we apply baselines to the Agile parts? Sometimes, that’s necessary too — especially when regulatory requirements demand it. CHAMP teaches you exactly how to do that. 

Shade of Grey # 5: Tracking Hybrid-Projects

Tracking is indispensable in any project. Even in Scrum projects, we use burndown and burnup charts. Once the initial scope is set, the schedule is defined, and cost expectations are established, it's time to track real progress against them. 

But then tracking also comes with a shade of grey, as different elements may follow different approaches. 

With CHAMP, you learn techniques such as Earned Value Analysis integrated with Agile metrics, and how to use MS Project’s tracking tools to update percent complete, actuals, and forecast variances.

Other Shades of Grey 

There are other shades of grey. In the CHAMP course, they are explained, elaborated, and demonstrated hands-on through real-world projects using the practical software tool MS Project Agile. I’ve highlighted a few above. 

Want to know more? Consider becoming a CHAMP. See here.

Conclusion

CHAMP is not a paper tiger course. It’s a hands-on, tool-driven, scenario-based certification. 

You don’t just learn theory needed, you also build hybrid plans hands-on, track real metrics hands-on, and generate reports hands-on.

The CHAMP certification exam is not a quiz! It’s a proving ground and practical-driven. The question standard, as reported by CHAMP certified professionals, is high.

The course includes over 100 exercises, two full-length practice Q&A sets, and a 15-day money-back guarantee. The emphasis is on hands-on mastery: from project setup, board configurations, and board management to applying Hybrid-Agile principles and management techniques. 

All of these are crucial for both your hybrid-agile certification and real-world application.

CHAMP Reviews and Success Stories:

• CHAMP Review: 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

ManagementYogi's CHAMP Certification Course:

• Certified Hybrid-Agile Master Professional (CHAMP)

Free CHAMP Questions:

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

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