Thursday, October 31, 2024

The CIPSA Framework – A Simple Clock View


The Certified In Practical Scaled Agile (CIPSA) is a very simple framework with hands-on applicability and full demonstrative usage of scaling using either Scrum or Kanban at the team level. In this post, I’ll outline the CIPSA Framework in a clock view.

The CIPSA Framework Clock

The below figure informs the CIPSA Framework Clock, or simply, the CIPSA Clock. 


As shown in above figure and as it happens in a clock, we have the following activities associatd with each clock pointer.

Clock Pointer 1: Establish the Product Goal.

Here the Product Goal is created by the Chief Product Owner (CPO). 

Clock Pointer 2: We have Cross-team Backlog Refinement. 

The Cross-Team Backlog Refinement happens. The Product Goal drives the top ordered items (content) of the Product Backlog.

Clock Pointer 3: With CIPSA Planning, Build the CIPSA Backlog.

The CIPSA Backlog will be built by the CIPSA Team. The CIPSA Backlog will have the CIPSA Goal, which is in alignment with the Product Goal.

Clock Pointer 4: In the Sprint/Release, Execute the Work Items.

For scaled Scrum, in the Sprint, the work items are executed. For scaled Kanban, in a release – based on cadence – the work items will be executed.

Clock Pointer 5: Conduct the CIPSA Daily Stand-ups.

The CIPSA Daily Stand-ups happen in the Sprint or Release and the needed representatives from the CIPSA team participate.

Clock Pointer 6: Remove issues, impediments and mitigate risks.

This happens through the Sprint or Release.

Clock Pointer 7: Ensure Continuous Integration.

Integration is not a one-time work, but happens continuously cutting across the individual teams under the CIPSA Team.

Clock Pointer 8: Have the CIPSA Integrated Increment.

The CIPSA Integrated Increment is the sum of all work coming from the individual teams.

Clock Pointer 9: Conduct the CIPSA Review.

This meta-event is the second to last one and the CIPSA Integrated Increment is presented here.

Clock Pointer 10: Update the Product Backlog. 

The Product Backlog can be updated based on the feedback received in the CIPSA Review meeting.

Clock Pointer 11: Conduct the CIPSA Retrospective.

This is the final meta-event for improvements. 

Clock Pointer 12: Repeat.

As the pointer name tells, repeat the work!

Video Explanation: The CIPSA Framework Clock 

The below video explains the CIPSA framework clock or simply the CIPSA clock. The duration is around 5 minutes [5m:32s]. Put your earphones (or buds) and go full HD in order to have a better experience. 


==

In summary, that’s what happens in the CIPSA Framework for scaling Scrum or Kanban teams. Yes, that’s all! 

Isn’t it a very simple framework to learn and use? 

Scaling frameworks need not be complex, heavy on documentation, but low on practical applicability and usage. In fact, for any real Scaled Agile practitioner, it should be the opposite! 

However, worldwide, not a single framework tells how to scale with software tools. If at all they do, it becomes very cumbersome with multiple tools and high complexities. 

The CIPSA Framework is not complex, but enables you to deliver work, which is complex!

The CIPSA Framework Clock demonstrates scaling in a simple manner. To know more on the CIPSA Framework, you can download the CIPSA Framework Guide.


References

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

[2] Scrum at Scale: Multiple Sprints and Synchronized Scaled Sprints with MS Project Agile, by Satya Narayan Dash

[3] Kanban at Scale: Managing Multiple Teams and Boards with MS Project Agile, by Satya Narayan Dash



Tuesday, October 22, 2024

Scrum at Scale: Differentiating Between Product Backlog and CIPSA Sprint Backlog

  

Like there are differences between the CIPSA Sprint Backlog and the Team Sprint Backlog, we also have differences between the Product Backlog and the CIPSA Sprint Backlog. When you go for the upcoming CIPSA Certification, you need to know the differences. In this article, we will explore a few differences. 

In one of the earlier articles, I wrote the following:

“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, but they are in the Team Sprint Backlog. This distinction is important to understand.”

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

Why CIPSA Sprint Backlog?

We need a CIPSA Sprint Backlog for the following reasons.

  • Adding of meta-events such as CIPSA Sprint Planning, CIPSA Daily Scrums.
  • Segregation of work items with respect to individual Scrum teams.
  • Assignment of Sprints across the individual Scrum teams.
  • Allocating resources to the work items.

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

Product Backlog and CIPSA Sprint Backlog

While the individual teams are sprinting, the entire CIPSA Scrum Team is also sprinting. It happening on the same Sprint number. While the backlog items are available in the Product Backlog, the final, ordered or prioritized items to be taken in the upcoming Sprint is at the CIPSA Sprint Backlog level.

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

Product Backlog Vs. CIPSA Sprint Backlog

Difference # 1: Product Backlog is a single one and stands on its own - separate, unique. CIPSA Sprint 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 (post prioritization) the CIPSA Sprint Backlog.

Difference # 3: The Product Backlog will have a Product Goal. The CIPSA Sprint Backlog will have a CIPSA Sprint Goal. The final goal is to reach the Product Goal by achieving a number of CIPSA Sprint Goals.

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

Difference # 5: The Chief Product Owner owns the Product Backlog. The CIPSA Team owns the CIPSA Sprint Backlog.

These differences are noted in the below table. 


Can you think of any other difference(s)? 

Video Explanation: Product Backlog Vs. CIPSA Sprint Backlog

The video below [duration: 04m:02s], explains the diferences between the Product Backlog and CIPSA Sprint Backlog. For better experience, plug-in your earphones and go full-screen HD. 


Closing Remarks 

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 Sprint Backlog.


References

[1] Scrum at Scale: CIPSA Sprint Backlog Vs. Team Sprint Backlog, 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

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


Friday, October 11, 2024

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