Both the Product Backlog and the CIPSA Kanban Backlog are key artifacts in the CIPSA Kanban Framework. However, from an execution point of view, the real action happens in the CIPSA Kanban Backlog, because it is the CIPSA Kanban Backlog that is executed by the CIPSA Kanban Team.
Product backlog items taken from the Product Backlog are executed by individual Kanban Teams, resulting in a CIPSA Integrated Increment at the end of the release. The following differentiations clearly define the characteristics of the CIPSA Kanban Backlog.
The content of this article is based on the CIPSA Kanban Framework. See here.
CIPSA Kanban Backlog – What It’s and What It’s Not
Among many, the following are some of the top ones:
1. Not Ongoing, but Release-Bound: The CIPSA Kanban Backlog is not a continuous artifact. The CIPSA Kanban Backlog is discarded when the Release ends.
The CIPSA Kanban Backlog is not kept for indefinitely and is not ongoing is nature. When one release is over, it’s discarded and another is taken-up.
2. Not a Superset, but a Subset: The sum of all CIPSA Kanban Backlogs across Releases is not equal to the Product Backlog. The CIPSA Kanban Backlog is a smaller, Release-specific subset.
There will be multiple releases while using the CIPSA Kanban Backlog. The sum of all CIPSA Kanban Backlog across releases doesn’t equal to the Product Backlog. It’ll always remain a subset of the Product Backlog. See here to learn more.
3. Not Just Tasks, but Also Meta-Events: The CIPSA Kanban Backlog does not only hold work items. The CIPSA Kanban Backlog also includes CIPSA Meta-Events.
Other than the work items, the meta-events included in the CIPSA Kanban Backlog can be CIPSA Kanban Planning, CIPSA Daily Stand-ups, CIPSA Kanban Review, and CIPSA Kanban Retrospective.
4. Not Self-Directed, but Facilitated: The CIPSA Kanban Backlog is not managed without guidance. The CIPSA Kanban Backlog is facilitated by the Principal Flow Master (PFM).
While the CIPSA Kanban Team owns the CIPSA Kanban Backlog and the team-members execute the tasks (from the individual Team Backlog), it’s not without guidance. The PFM provides the necessary guidance.
5. Not Isolated, but Dependency-Aware: The CIPSA Kanban Backlog does not ignore inter-team needs. The CIPSA Kanban Backlog allows inter-team dependencies to be noted and tracked.
The inter-team dependencies, i.e., the dependencies across the individual Kanban Teams are noted in the CIPSA Kanban Backlog. With right software tool(s), it’s highly useful.
CIPSA Kanban Backlog – Summary Table
The summary table is shown below.
Final Words
I believe the above differentiations will bring a lot of clarity regarding the CIPSA Kanban Backlog. Detailed explanations will be part of the CIPSA certification course.
Want to experience it hands-on? Become a CIPSA. It’s world’s only Practical Scaled Agile certification.
Among many things, you’ll learn:
- How to build the CIPSA Kanban Backlog?
- How to associate with single- or multi-Releases?
- How to go with both CIPSA Kanban Backlog and Team Kanban Backlogs?
- What are the various ways to assign resources at Scale?
- When, why and how to schedule CIPSA Kanban Backlog related events?
--
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 and Questions:
CIPSA Sample Questions:
CIPSA Certification:

.png)
No comments:
Post a Comment
Sign- or Log-in and put your name while asking queries in comments. Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.