Kanban at Scale: Product Backlog Vs. CIPSA Kanban Backlog

In the CIPSA Framework, world’s only practical scaled agile framework, we have three backlogs: Product Backlog, CIPSA Backlog, and Team Backlog. Considering the CIPSA Kanban Framework, the CIPSA Backlog will be called the CIPSA Kanban Backlog.  In this article, we will explore the differences between Product Backlog and CIPSA Kanban Backlog.

In one of the earlier articles related to the CIPSA Kanban Framework, I wrote the following:

“In the CIPSA Kanban Planning meeting, a CIPSA Kanban Backlog is created with the Product Backlog items that can be delivered by multiple teams in the upcoming release. Post CIPSA Kanban Planning meeting, for each team, an individual team level Kanban Planning event takes place. This results in a Team Kanban Backlog for each team.”

Now, if the Product Backlog items are directly taken into the CIPSA Kanban Backlog, but we are actually executing the items in the Team Kanban Backlog, two questions come-up:

• What is the need of CIPSA Kanban Backlog? We already have Product Backlog and Team Kanban Backlog.
• If needed, what exactly are the differences between the Product Backlog and CIPSA Kanban Backlog?

Do note that while my explanation is specific to the CIPSA Kanban Framework, similar concepts are in the CIPSA Scrum Framework.

Why CIPSA Kanban Backlog?

First and foremost, we don’t execute the entire Product Backlog, but parts of it. Considering the Kanban framework, we have a CIPSA Kanban Backlog due to the following reasons:

1. We need to clearly segregate the items taken for the upcoming Release for all the Kanban teams. 
2. We need to add the meta-events into a backlog where the CIPSA Team will not be executing the work items, but also a plan for the meta-events such as CIPSA Kanban Planning, CIPSA Daily Stand-ups etc.
3. Segregation of Kanban teams (human resources) need to happen. This can happen only at the CIPSA Kanban Backlog level.
4. Allocation of resources doesn’t happen at the Product Backlog level. It can only happen at CIPSA Kanban Backlog and Team Kanban Backlog level. 

Hence, the CIPSA Kanban Backlog is created from the Product Backlog. It’s depicted in the figure below.

Next, let’s see the differences between the Product Backlog and the CIPSA Kanban Backlog.

Product Backlog Vs. CIPSA Kanban Backlog

Difference # 1: Product Backlog is a single one and stands on its own - separate, unique. CIPSA Kanban Backlog comes from the Product Backlog. 

Difference # 2: The Product Backlog will have the product backlog items. Some of the product backlog items will be part of the CIPSA Kanban Backlog.

Difference # 3: Product Backlog is a live document and continuously updated. The CIPSA Kanban Backlog will be for a Release and when the Release is over, it’s discarded.

Difference # 4: The Chief Product Owner (CPO) owns the Product Backlog. The CIPSA Team owns the CIPSA Kanban Backlog. If a complex service is delivered, then the CPO role will be replaced by Chief Service Request Manager (CSRM).

Difference # 5: The Product Backlog doesn’t contain any meta-events. The CIPSA Kanban Backlog will contain meta-events such as CIPSA Planning, CIPSA Daily Stand-ups, among others.

These differences are noted in the below table. 

Video Explanation: Product Backlog Vs. CIPSA Kanban Backlog

The video below [duration: 04m:38s], explains the diferences between the Product Backlog and CIPSA Kanban Backlog. For better experience, plug-in your earphones and go full screen with high-definition (HD). 

Before we close:

Can you think of a few other differences? Give it a try!

Closing Remarks

I believe you tried the above question! Now, you’d be thinking if there are any similarities between the Product Backlog and the CIPSA Kanban Backlog. One can think of the following ones: 

1. Like Product Backlog is one of the key artifacts in CIPSA Kanban framework, the CIPSA Kanban Backlog is also a key artifact.
2. Considering practical, hands-on approach (after all the CIPSA framework is mainly about that!), the Product Backlog Items and the CIPSA Kanban Backlog’s high-level items will be summary-level tasks. 

To know more about the roles (accountabilities), artifacts and events/meta-events, you can download the CIPSA Framework Guide. When you go through it, you will discover more differences on your own!

I believe this article gives you more clarity with respect to the differences between the Product Backlog and CIPSA Kanban Backlog.

References

[1] A Closer Look at the CIPSA Kanban Framework, by Satya Narayan Dash

[2] Introducing Practical Scaled Agile Framework with CIPSA Certification, by Satya Narayan Dash and ManagementYogi.com 

[3] New Practical Scaled Agile Framework – The CIPSA Framework Guide, by Satya Narayan Dash and ManagementYogi.com 

[4] Kanban at Scale: Managing Multiple Teams and Boards with MS Project Agile, by Satya Narayan Dash, first published by MPUG.com 

Scrum at Scale: CIPSA Sprint Backlog Vs. Team Sprint Backlog

In one of the recent articles, I wrote the following (summarized):

“A CIPSA Sprint Backlog is a collection of individual Team Sprint Backlogs. The individual teams sprint towards the individual Team Sprint Goals and execute the work items. Simultaneously, the entire CIPSA (Scrum) Team is also sprinting, but towards the CIPSA Sprint Goal!”

You can read the complete article here.

It has detailed explanations with videos, which you should watch to have more clarity. Most important of all, it’s shown with MS Project Agile software in a hands-on manner. The CIPSA Framework is the only framework in the world which demonstrates scaling in a practical, hands-on manner. The upcoming CIPSA certification will be based on this framework. 

CIPSA Team Sprinting Vs Individual Team Sprinting

If you look at the headline of this subsection, I’ve differentiated between the sprinting of the CIPSA Team and Individual Scrum Teams.

Sprinting is done to execute the work items, i.e., tasks in the backlogs. The line items in the CIPSA Sprint Backlog are taken from the Product Backlog. In the CIPSA Sprint Backlog, the items are not broken down into individual tasks. That happens in the Team Sprint Backlog. This distinction is important to understand and it’s depicted in the figure below.   

CIPSA Sprint Backlog Vs. Team Sprint Backlog

Now, let’s see the differences between the CIPSA Sprint Backlog and the Team Sprint Backlog. 

Difference # 1: CIPSA Sprint Backlog comes from the Product Backlog. On the other hand, the Team Sprint Backlog comes from the CIPSA Sprint Backlog.

Difference # 2: CIPSA Sprint Backlog will have the product backlog items. The Team Sprint Backlog will have task line items.

Difference # 3: The “what to do” in the upcoming Sprint is informed by the CIPSA Sprint Backlog, whereas the “how to do” in the upcoming Sprint is informed with the Team Sprint backlog.

Difference # 4: The CIPSA meta-events such as CIPSA Sprint Planning, CIPSA Daily Scrum, CIPSA Sprint Review and CIPSA Sprint Retrospective will be part of the CIPSA Sprint Backlog. 

The Scrum Events such as Sprint Planning, Daily Scrum, and Sprint Retrospective will be part of the Team Sprint Backlog.

Difference # 5: The CIPSA Sprint Goal is part of the CIPSA Sprint Backlog, but the Team Sprint Goal will be part of the Team Sprint Backlog. For a Sprint, there is one CIPSA Sprint Goal, but there can be multiple Team Sprint Goals depending on the number of Scrum Teams.

The differences are noted in the below table.

To know more about the roles (accountabilities), artifacts and events/meta-events, you can download the CIPSA Framework Guide. When you go through it, you can find out more differences on your own!

How about the similarities?

The following can be listed:

• Sprint Number: The Team Sprint Backlogs will be with respect to the same Sprint number, e.g., Sprint 7. All individual Scrum Teams will also be sprinting in Sprint 7. The CIPSA Sprint Backlog will also be with respect to the same Sprint number, i.e., Sprint 7. The entire CIPSA Team will also be sprinting in Sprint 7.
• Timeboxing: All the (meta) events of CIPSA Scrum Framework, like the events at the individual Team Scrum framework, will be timeboxed.

Video Explanation: CIPSA Sprint Backlog Vs Team Sprint Backlog

The video below [duration: 05m:56s], explains the diferences between the CIPSA Sprint Backlog and Team Sprint Backlog.  

I believe you’ve gone through the CIPSA Guide. Can you think of any other differences and/or similarities?

Concluding Remarks

I always believed simple things are easy to remember, implement and use. Complex ones get more and more complex and you finally give-up.

CIPSA is a very simple and easy to follow framework, unlike other scaled agile frameworks which come with a lot of theories. It’s also practical and hands-on. 

I hope this article gives you more clarity with respect to the differences between the CIPSA Sprint Backlog and Team Sprint Backlog.

References

[1] Introducing Practical Scaled Agile Framework with CIPSA Certification, by Satya Narayan Dash

[2] New Practical Scaled Agile Framework – The CIPSA Framework Guide, by Satya Narayan Dash and ManagementYogi.com

[3] Scrum at Scale: Managing Multiple Teams and Boards with MS Project Agile, by Satya Narayan Dash, first published by MPUG.com

ManagementYogi’s Hybrid-Agile (CHAMP) Certification: Retrospective Boards in Hybrid-Scrum Projects (2)

In the first part of this article, we saw the following:

• A Retro Board and Out Current Scenario
• Creation of the “isRetro” custom field
• Creation of Retro Board Filter
• Creation of the Retro Board 

In this post, we will visualize the retrospective work items in the boards, associate them with the Sprints as well as manage the retrospective work items. 

Towards the end, we have certain key points to note followed with concluding remarks.

[Part - 1]

Visualizing the Items in the Board

From your current view, switch to the Retro Board. This can be done by going to View tab > Task Views group and then selecting the Retro Board from the custom section. 

This will result in the display of the newly created Retro Board view.

As shown in the above Retro Board view, all the retro items are part of the Backlog column.

• There are other columns such as TODO, DOING and DONE. 
• I’ve customized the existing columns by renaming them.
• % Complete values are also customized. 

Do note that there is no Sheet view related to Retro Board view because we have not created one. As you proceed and use the board, we won’t be needing a sheet view. Hence, this corresponding view need not be created. 

Associate Improvement Items with Sprints

Next, we are going to associate the work items with the upcoming Sprint. This will happen during the Sprint Planning Meeting for Sprint 2. Do note that at this stage, Sprint 1 complete with all its work items. The Sprint Planning Board view at this stage will look as follows.

As you can see in the above figure, all Sprint 1 are completed. Next, as you take the retrospective items for Sprint 2 and associate them with Sprint 2, you will have the following view in the Gantt Chart.  

So, let’s see these items in the Retro Board view, too. But before that, one more twist! We have to customize the Cards to know the Sprints or which Sprint they belong to. This can be done by going to Task Board Tools > Format tab > View group > Format command. It’ll launch the Customize Task Board Cards dialog box as shown below. 

As shown, Sprint is now added as one of the fields, so that we clearly know which items are taken for in which Sprint. 

With the above customization, the Retro Board will now come as shown as below.  

Customizing the cards provides you with a better visualization as you manage and track the items. 

As shown above, now the cards are customized for each retro work item, and they show:

• ID, Names, Durations, Start and Finish dates.
• It also shows the Sprint names.

Manage Retro Work Items 

To manage, you have to simply drag and drop the work items, move them across the workflow states as it happens for other works items in the Hybrid-Scrum project. When a work item reaches the DONE state, then you’ll find a tick mark towards the top right corner of the card. This is shown below.

If you have come this far, then you can quickly create a Retro Board, populate the work items, associate them with the Sprints and track them to completion. 

This can be seen as well in the Hybrid-Scrum project with all the elements, which is shown below.

As you can see in the above figure, for our Hybrid-Scrum project, Sprint 1 is complete and Sprint 2 is currently under execution. For Sprint 2, you are not only completing the feature related work items, but also completing retrospective items. 

Key Points to Note

As we reach the end of this article, here certain key points to note about Retro Board and associated items:

• It can be used in Lean-Agile (Scrum or Kanban), or Hybrid-Agile projects. Hence, don’t have to create a separate project. The created retro board is integrated in.
• Retrospective items are also part of your (Product) Backlog. This we saw in the earlier parts of this article. 
• Your team should take a few items, at most 2 for the next iteration or Sprint. When taken they will be part of the Sprint Backlog. Ensure that they are tracked and completed.
• The retrospective items can be seen in the Current Sprint Board view because they are associated with respective Sprints.
• The retro items can be considered as part of the Burndown Charts and Burnup Charts.  

Demonstration

A demonstration for the Retro Board is shown in the below video [duration: 04m:14s]. 

Conclusion

As the saying goes, simple things are always easy to remember compared to complex things. I believe this is the simplest way to track the retro items in a separate board. 

It also a good idea to track the items in a separate board because the retrospective items are usually neglected by Lean-Agile teams as feature completion fever takes over considering the small iteration duration. However, as I noted in the beginning, retrospective is the most important ceremony among all and to honor it, you need to take and execute the retro work items. 

[Part - 1]

--

This article was first published by MPUG.com on 5th March, 2024. This is a refined version.

References

[1] Online Course: ACP Live Lessons – Guaranteed Pass or Your Full Money Back, by Satya Narayan Dash

[2] Certification Course: Certified Hybrid-Agile Master Professional (CHAMP), by Satya Narayan Dash

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

[4] Online Course: Mastering MS Project Agile, by Satya Narayan Dash

ManagementYogi’s Hybrid-Agile (CHAMP) Certification: Retrospective Boards in Hybrid-Scrum Projects (1)

Retrospective is an important event in Agile. In fact, I’d say the most important one. This is a meeting where the team finds out what they could have done better and what the improvement items are. Not only that, they will also have an execution plan to take up the improvement items.

At this point, it’s important to note that retrospectives and lessons learned meetings are not same! Retrospective also differs from intraspectives. While lessons learning meetings are conducted to identify and share the lessons learned in a project, phase or iteration to improve, retrospectives, on the other hand, are recurring events in Lean-Agile to explore the work done and improve based on the results. For for Scrum, it is at the end of the Sprint, whereas for Kanban, it’s can be based on cadence. Nevertheless, one can say retrospective is a form of lessons learned meetings.

[Part - 2]

A Retrospective Board

The quickest way to take the retrospective items and implement them is by using the Retrospective Boards. The simplest ones are with the following columns in the board:

• Stop doing, Start doing, Keep doing (or simply StoStaKee)
• Stop, Start, Stay (or SSS, Triple S)
• Same as, More of, Less of (or SAMOLO)

The above concepts are taken from ACP Live Lessons - Guranteed Pass. Let’s take the first one of StoStaKee. A sample board can be shown as below. 

For this article, our focus is on the items which we want to do or execute the improvement items, which are in the “Start Doing” column. 

These items will be taken into our Hybrid-Agile plan, put into the Retrospective Board and be executed. I’d strongly recommend that you check this article of Hybrid-Scrum management, before going deeper into this article.  

Current Scenario: Our Hybrid-Scrum Project

We will take the plan from our earlier Hybrid-Scrum project, where we have multiple Sprints planned along with the predictive/waterfall elements. One of the Sprints is complete and at the end of the Sprint quite a few retrospective items were decided to be taken-up. This is shown in the below figure. 

As shown in the multi-Sprints Scrum Development phase, we have completed Sprint 1. In the next Sprint’s (Sprint 2) planning meeting, the retrospective items that can be executed will be taken-up and planned for.   

Next, let’s proceed with our creation of the Retrospective Board with MS Project Agile software tool. The board will have the retro work items. We will have the following steps.

Create isRetro Custom Field

As shown, first you have to create the isRetro custom field. It’s a Boolean Field.

 

You don’t have to change the:

• Custom attributes
• Calculation for assignment rows
• Values to display

Just keep it simple, though further customization can be done.

Create a Retro Board Filter

Next, we will use the Retro Board Filter, a new custom filter. This can be created by going to View tab > Data group > Filter option > More Filter dialog box. In the opened-up box click on the “New…” command to create a new filter. 

As shown below, the new filter created is Retro Board filter. 

The above filter has the following parameters:

• Show on Board is “Yes” or enabled.
• Summary (Tasks) is “No” or disabled.
• %Work Complete is 100%, i.e., incomplete work items will be shown.
• Active is “Yes”, i.e., only Active tasks will be shown.
• isRetro custom field is enabled for this filter. We have created this custom field before.

Create the Retro Board

Next, we will create the Retro Board, which will internally have the Retro Board filter that we just created. 

To create such a board, go to View tab > Task Views group > Task Board drop down > More Views… command. This will open-up the More Views dialog box, where you can create a new Retro Board using the “New…” command. 

As shown below, we have the Retro Board view available with the Retro Board Filter applied. Don’t forget to apply this filter.  

Ensure to enable the “Show in menu” option, which helps in showing the Board when you quickly need it.

Add the Retrospective Items

As and when retrospectives happen in your Hybrid-Scrum project, you can add the improvement work items into the task items and hence the board. For this purpose, I’ll have another summary task and put all my retrospective items under that summary task.

Now, you may be wondering why not keep these items as parts of the Sprint? You can! But it’s not very effective. Also, you really don’t know which items will be taken in which Sprint. Do you? Rather, the items will be prioritized and then taken. 

As shown below I’ve a summary task Retrospective Items, under which I’ve a number of retrospective work items.  

Also, as you can see in the above figure:

• No Sprint has been associated with the Retro work items.
• The Show on Board field has been enabled.
• The duration is not decided for the work items.

We can’t decide on the work items’ duration as that will happen during the upcoming Sprint’s planning meeting. Also, it’s a good idea and practice not to take more than 3 items for the upcoming Sprint. As I’ve seen, effectively, a Scrum Team can complete at most one or two items for an upcoming short Sprint of 2-week duration. 

Next, we are going to visualize these work items in the newly created Retro Board.

The concluding part of this article is available here.

[Part - 2]

References

[1] Online Course: ACP Live Lessons – Guaranteed Pass or Your Full Money Back, by Satya Narayan Dash

[2] Certification Course: Certified Hybrid-Agile Master Professional (CHAMP), by Satya Narayan Dash

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

[4] Online Course: Mastering MS Project Agile, by Satya Narayan Dash

A Closer Look at the CIPSA Kanban Framework – Practical, Hands-on Kanban at Scale

Many organizations and teams choose Kanban. In fact, in my work such as preparing professional courses, certifications or writing management books, I personally use certain aspects of Kanban. There are dates I’ve to meet, which may not be every week or two weeks, but release will happen on a cadence. The work is mostly iterative and incremental. In this way, it becomes Kanban, a Lean-Agile approach.

ManagementYogi's CIPSA Framework is practical and hands-on. It uses MS Project Agile software, which provides both Scrum and Kanban capabilities. The CIPSA framework uses both Scrum and Kanban at the team level. In this post, we will learn more on CIPSA Kanban Framework.

The CIPSA Kanban Framework

The CIPSA Kanban framework extends the team level Kanban and will have the following artifacts, events and roles.

CIPSA Kanban Artifacts: There are three artifacts:

• Product Backlog, 
• CIPSA Kanban Backlog, and
• CIPSA Integrated Increment.

All individual Kanban teams use a single Product Backlog. The Backlog items are distributed across the teams. 

A CIPSA Kanban Backlog is built during the CIPSA Kanban Planning event, and it's the sum of all work done by individual Kanban teams for the upcoming release. The release is usually based on a cadence. Some CIPSA practitioners call the CIPSA Kanban Backlog as a CIPSA Kanban Program Backlog. 

The third artifact is the CIPSA Integrated Increment, which is the sum of all integrated work from all Kanban teams and is given at the end of the release. 

CIPSA Kanban Events: There are Six Events in CIPSA Kanban framework: 

• Cross-Team Backlog Refinement,
• The Release,  
• CIPSA Kanban Planning,
• CIPSA Daily Stand-ups, 
• CIPSA Kanban Review, and 
• CIPSA Kanban Retrospective. 

CIPSA Kanban Roles: There are two distinct roles in CIPSA Kanban Framework complementing the accountabilities at the individual team level. They are: 

• Chief Product Owner (CPO) or Chief Service Request Manager (CSRM)
• If you are building a large product, then it’d be a CPO. On the other hand, if you are offering a large service-based solution, then it’d be a CSRM.
• Sometimes, the CPO and CSRM can be interchangeably used.
• Principal Flow Master (PFM). 

At the individual team level, there will be Product Owner (or Service Request Manager), Flow Master and Developers. 

The CIPSA Kanban Framework – Graphical

The CIPSA Kanban framework is shown in the below figure. 

The CIPSA Kanban Framework – Interactions

A single Product Backlog with ordered items is continuously refined with cross-team members as part of the Cross-Team Backlog Refinement meta-event or meeting. The Product Backlog with the is presented by the CPO or CSRM in the CIPSA Kanban Planning event of the upcoming release. In this meeting, a CIPSA Kanban Backlog (CIPSA Kanban Program Backlog) is created with the Product Backlog items that can be delivered by multiple teams in the upcoming release. 

Post CIPSA Kanban Planning meeting, for each team, an individual team level Kanban Planning event takes place. This results in a Team Kanban Backlog, for each team. 

Next, each team begins to work on the respective Team Kanban Backlog items. The CIPSA Daily Stand-up meta-event happens regularly, and it’s preceded by an individual team-level Daily Stand-up for the individual Kanban teams. 

In the CIPSA Kanban Review meeting, a CIPSA Integrated Increment is presented to the entire CIPSA team and needed stakeholders. The CIPSA Kanban Review meeting replaces the individual Team Kanban Reviews. 

The last event for CIPSA Kanban Framework is CIPSA Kanban Retrospective. Here the CIPSA team reflects on the effectiveness of the CIPSA team as a whole and determines the improvements that can be taken-up. This meeting is preceded by Team Kanban Retrospective, which is specific to the individual teams.  

Video: The CIPSA Kanban Framework

The video below [duration: 05m:56s], explains the CIPSA Kanban Framework with some more points. 

Conclusion

As you’re coming to the end of this article, you’d have noticed that naming convention changes based on the framework being used – Scrum or Kanban. For example, CIPSA Planning meta-event is called CIPSA Sprint Planning, whereas for Kanban it’s called CIPSA Kanban Planning.

Similarly, the CIPSA Sprint Planning meta-event creates the CIPSA Sprint Backlog, whereas in Kanban, we get a CIPSA Kanban Backlog or CIPSA (Kanban) Program Backlog. 

I’m highlighting it as the CIPSA framework is quite simple to understand and follow. However, just knowing the theory won’t really help you much. You also need to know:

• How does it happen in the real-world?
• As a CPO, PSM or PFM, how would you manage a large product or service?
• How to manage a number of Sprints across multiple teams in a simple manner (in CIPSA Scrum)?
• How will the CIPSA meta-events and team events be created?
• How would you track such a plan?

All these will be part of the upcoming CIPSA certification course.

Above all, this article is about a closer look at the CIPSA Kanban Framework. The above video provides a brief explanation to enhance your learning. As recommended in the above video, download the CIPSA Framework Guide to understand more. 

References

[1] Introducing Practical Scaled Agile Framework with CIPSA Certification

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

[3] Article, Kanban at Scale: Managing Multiple Teams and Boards with MS Project Agile

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

Two Lean-Agile approaches are popular and widely used at the Team Level – Scrum and Kanban. The CIPSA framework recognizes this and hence, uses both of them. You can choose the approach you want for your organization and can scale using the CIPSA framework. 

MS Project Agile is a widely used project-portfolio management software tool with extensive Agile capabilities. It also supports both Scrum and Kanban such as Sprints, Boards related to Sprints as well as Boards and Views related to Kanban.

In this post, we will learn more on CIPSA Scrum Framework.

The CIPSA Scrum Framework

The CIPSA Scrum framework extends the team level Scrum and will have the following artifacts, events and roles (accountabilities).

CIPSA Scrum Artifacts: There are three artifacts:

• Product Backlog, 
• CIPSA Sprint Backlog, and
• CIPSA Integrated Increment.

All individual Scrum teams use a single Product Backlog. The Backlog items are distributed across the teams. 

A CIPSA Sprint Backlog is built during the CIPSA Sprint Planning event and it's the sum of all work done by individual Scrum teams for the upcoming Sprint.

The third artifact is the CIPSA Integrated Increment, which is the sum of all integrated work from all Scrum teams and is given at the end of (or during) the Sprint. 

CIPSA Scrum Meta-Events: There are Six (Meta) Events in CIPSA Scrum framework: 

• Cross-Team Backlog Refinement,
• The Sprint, 
• CIPSA Sprint Planning,
• CIPSA Daily Scrum, 
• CIPSA Sprint Review, and 
• CIPSA Sprint Retrospective. 

CIPSA Scrum Roles: There are two distinct roles in CIPSA Scrum Framework complementing the accountabilities at the individual team level. They are 

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

At the individual Scrum team level, there will be Product Owner and Scrum Master and Developers. 

The CIPSA Scrum Framework – Graphical

The CIPSA Scrum framework is shown in the below figure. 

The CIPSA Scrum Framework – Interactions

A single Product Backlog with ordered items is continuously refined with cross-team members as part of the Cross-Team Backlog Refinement event. The Product Backlog with the Product Goal is presented by the CPO in the CIPSA Scrum Planning (meta) event of the upcoming Sprint. In this meeting, a CIPSA Sprint Backlog is created with the Product Backlog items that can be delivered by multiple teams in the upcoming Sprint. 

While individual Scrum teams are sprinting on their own, the Sprints are synchronized across the Scrum teams.

Post CIPSA Scrum Planning meeting, for each team, an individual team level Sprint Planning event takes place. This results in Team Sprint Backlog, for each team. 

Next, each team begins to work on the respective Team Sprint Backlog items. A CIPSA Daily Scrum meeting happens everyday and it’s preceded by individual team-level Daily Scrums for the individual teams. 

In the CIPSA Sprint Review meeting, a CIPSA Integrated Increment is presented to the entire CIPSA Scrum team and needed stakeholders. The CIPSA Sprint Review meeting replaces the individual Team Sprint Reviews. 

The last event for CIPSA Scrum Framework is CIPSA Sprint Retrospective. Here the CIPSA team reflects on the effectiveness of the CIPSA team as a whole and determines the improvements that can be taken-up. This meeting is preceded by Team Sprint Retrospective, which is specific to the individual teams.  

Video: The CIPSA Scrum Framework

The below video [duration: 6m:34s], explains the CIPSA Scrum Framework briefly with the roles, meta-events, and artifacts. 

Conclusion

As noted earlier, the CIPSA Scrum Framework extends the team-level Scrum. Hence, the CIPSA Scrum framework and team-level Scrum are in harmony. In fact, most of the events, roles and artifacts followed by Scrum are directly employed in the CIPSA Scrum Framework – but at scale.

The CIPSA Scrum Framework is practical, hands-on and uses a single software tool – MS Project Agile. This is the ONLY such framework in the world! With practical applicability, you have a much better learning, understanding and applicability in your scaled Scrum team or organization.

References

[1] Introducing Practical Scaled Agile Framework with CIPSA Certification

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

[3] Scrum at Scale: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile

New Practical Scaled Agile Framework – The CIPSA Framework Guide

In the earlier post, I informed about a new Practical Scaled Agile framework and associated certification – Certified In Practical Scaled Agile (CIPSA). 

Today, I’m pleased to announce the public availability of the CIPSA Guide to Scaling Scrum or Kanban Teams with the MS Project Agile software. You can download the guide for free, read and use it.

Purpose of the CIPSA Guide

Building a large-scale product or service is complex work and involves multiple teams. Worldwide, a large number of scaled agile frameworks are available, but not a single one of them considers taking a practical, hands-on approach using software tools.

The Practical Scaled Agile (PSA) framework is built-upon the widely used Lean-Agile approaches such as Scrum or Kanban. The Lean-Agile approaches are documented in respective guides and beyond the scope of this guide. 

Certified in Practical Scaled Agile (CIPSA) is the direct certification associated with Practical Scaled Agile (PSA) framework. Hence, going forward, I’ll call it CIPSA (sip-sa) Framework. 

A CIPSA professional will have a deeper and much clearer understanding of CIPSA framework as the person would know in and out the Practical Scaled Agile using the software tool of MS Project Agile.   

This guide contains the definition of CIPSA framework. Each element of the framework serves a specific part in order to help teams and organizations scale the benefits of two popular Lean-Agile approaches: Scrum and Kanban.

This framework has two objectives:

• Scaling using either Scrum or Kanban at the team level and understanding various scaling aspects. 
• Strong emphasis with hands-on demonstration with software tools such as MS Project Agile. In fact, in the annexures you can find a number of real-world snapshots. 

A number of Scaled Agile practitioners and authors at ManagementYogi.com contributed to the development of the CIPSA framework. In particular, Satya Narayan Dash would like to thank John P S Oliver, Lakshmi Narayan Dash and others at ManagementYogi for their contributions in the development of this guide.

CIPSA Definition

Certified In Practical Scaled Agile (CIPSA) is a framework, in which a set of Lean-Agile teams with interdependencies operate together to build products or solutions for complex problems using hands-on software tools such as MS Project Agile. In this framework either Scrum or Kanban can be applied at the team level and it can be scaled to multiple teams.

With the CIPSA framework and as a CIPSA professional, one can scale multiple teams to deliver a single large product or service. In it, the Chief Product Owner manages a Single Product Backlog with individual Team Product Owners focused on individual Team Sprint Backlog or Kanban Backlog. 

This guide outlines various events, artifacts, commitments and accountabilities of the CIPSA framework. With scaling, multiple teams work on a single Product Backlog to build and deliver an Integrated Increment. The delivery can be within or at the end an Iteration (Sprint) as in Scrum or a cadence-based Release as in Kanban.

The CIPSA Guide 

The CIPSA Framework Guide (20 pages) is embedded in this page. It’s free to view, download and read. To view, just scroll using the vertical bar to go through the guide.

You can directly download the CIPSA Guide from the below link:

Download the CIPSA Framework Guide

No sign-in is required to download.

Video: Understanding the CIPSA framework Guide

The below video explains the guide and how to proceed with the guide, along with the contents. It's brief video, less than five minutes.

Final Words

This new Practical Scaled Agile Framework is radically different from others because it’s highly focused on practical applicability, hands-on usage while scaling and in-depth practical demonstration. All these will be part of the upcoming CIPSA Certification Course.

Below are some of the snippets taken from the above CIPSA Guide. 

The cross-team refined Product Backlog with MS Project Agile software is shown below. 

The multi-team, multi-Sprint view for the entire CIPSA Team is shown below. 

The CIPSA Sprint Burndown Chart for the entire CIPSA Team is shown below. Individual team level Burndown Chart can also be drawn and it's informed as part of the CIPSA Guide. 

You can check them all the available linked and downloadable document. Go on, it’s free to download and read. A CIPSA professional (CIPSA Certified) will know in and out of Scrum at Scale and Kanban at Scale using the CIPSA Framework and MS Project Agile software.

I welcome your feedback and inputs on the CIPSA Framework. It'll help many other Scaled Agile Practitioners. 

References

[1] New Practical Scaled Agile Framework: The CIPSA Framework Guide (FREE Download), By Satya Narayan Dash and ManagementYogi.com

[2] Article: Kanban at Scale Managing Multiple Kanban Teams and Boards with MS Project Agile, By Satya Narayan Dash, first published at MPUG.com 

[3] Article: Scrum at Scale: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile, By Satya Narayan Dash, first published at MPUG.com