The Certified In Practical Scaled Agile (CIPSA) course embodies a dynamic and transformative spirit, captured vividly in the latest trailer (26 seconds). CIPSA is pronounced as 'sip-sa'.
The course is hands-on and deeply practical. It's also highly economical. It allows learners to master Scaled Scrum and Scaled Kanban in a hands-on manner with the needed theory.
The below table shows a brief comparison between CIPSA and other certification. Rating is given for each category based on inputs from CIPSAs. The star rating given is based on a scale where five stars represent the highest and one star, the lowest.
Check the items one-by-one to determine the value.
Whether you're navigating Scrum at Scale or Kanban at Scale, CIPSA equips you to rise above conventional limitations and embrace a new Scaled Agile excellence. It's unique in its approach.
The course is now used by Scaled Agile practitioners around the world.
CIPSA not just a certification – it’s a movement to have real-world learning and applicability, which seriously lacks in every other Scaled Agile certification. Rest of the scaled agile certifications are not at all practical, but only theory and more theory.
To really learn Agile scaling, consider becoming a CIPSA. It’s worth your money.
I’ve been certified Project Management Professional (PMP) from PMI and hence wanted to advance my knowledge, understanding and application of Risk Management in a deeper way.
Hence, I decided to go with the Risk Management Professional (RMP), which is considered to be valuable in my field of work.
Why ManagementYogi’s RMP 30 Contact Hours
The RMP 30 contact hours program from Management Yogi gives you a practitioner-first approach and it’s an exam-true program. It blends PMI-RMP exam alignment with field-grade techniques.
With this contact hours course, I believe I received a clean path for not only my exam, but also subsequent application.
RMP 30 Contact Hours Course: Key Features
Management Yogi’s RMP 30 Contact Hours stands out for a practitioner-first structure with concise videos that move from concept to application to short practice. The course maintains a strong governance lens around thresholds, reserves, authority, and change control, and its exam-style scenarios reflect PMI wording and decision patterns.
The topics that helped me most were data quality assessment before qualitative analysis, response strategy trade-offs across threats and opportunities, and clear reserve policies with drawdown rules.
This course covers the advanced content fully:
Expected Monetary Value (EMV) Analysis
Decision Tree Analysis (DTA)
Earned Value Management (EVM)
Sensitivity Analysis with Tornado Charts
Various Probability Distributions
Selecting appropriate distributions such as Triangular, BetaPERT, and Lognormal
Correlation in Risk Management
Monte Carlo Analysis and its interpretations with percentiles and drivers
In addition, it covers the areas of the PMBOK Guide, 7th edition and 6th edition with special emphasis on Risk Management. It covers:
Agile Management considering risks
Hybrid Management considering risks
Various associated Risk Artifacts
Risk Attitude Spectrum
Own Study for the RMP Exam
For practice, the combination of chapter-end questions for retention, full-length exams for pacing, and new items aligned to current standards, PMBOK 7 and 6, and agile and hybrid references were effective. Hence, I used and practiced them all.
While studying, I found the below ones most useful:
Quantitative analysis with many techniques outlined above
Plan and implement risk responses
Practical tool snapshots that map insights into scheduling platforms like Primavera or Microsoft Project
These made my workplace adoption straightforward.
The formula sets are concise and usable for exam preparation and day-to-day work, and the revision tips throughout the course and checklists were genuinely helpful for my final reviews.
Contact Hours Assessment
The assessmentfor the 30 contact hours was fair, aligned to the content, and served as a clear consolidation of learning rather than a surprise test. Post the assessment, I received the completion certificate.
Final PMI-RMP Exam
After receiving the contact hours certificate, I went for RMP application fill-up and submitted the application. Post approval, I took the exam in Canada and successfully cleared the exam on 27th September, 2025.
Conclusion
I want to apply my learnings in my profession and field work.
Brief Profile: Vallabha Chebiyyam, RMP, PMP
Assistant Project Manager: I’m working as a management and leadership professional with an engineering background and is based out of Canada.
In the realm of a project, certainty is a rare, though a welcome, guest. A project, which is a temporary endeavor, unfolds within a landscape filled with ambiguities, changing conditions with unforeseen twists and turns.
Such things are the norms, not the exceptions. Risk, then, is not an intruder, but a native of this terrain.
Risk Management in a Project
Project management rises in this uncertain landscape as it tries to bring certain order and structure amidst turbulence, sometimes even chaos. Project management is the steady hand that tries to sketch order onto the fog of uncertainty. While doing so, Project Managers (PMs) must court risk, not shun it. For to manage projects is to manage its risks! It’s a not a separate, but an indispensable function.
It's the job of the PM to anticipate the tremors before the project ground is shaken and to reap rewards when the sun shines upon the project terrain. For to address risks without any anticipation of rewards, is not a wise act. In other words, whether the project is a gentle stream or a turbulent sea, the PM must know the language of risks and risk management.
Thus, when a project management software tool offers the intelligence to navigate and address risks, it becomes more than a software. It becomes a partner because of its embedded risk management capabilities, which can in turn empower PMs to lead with clarity, confidence and conviction.
In my upcoming webinar, we will exactly do that with Primavera P6 software tool, which provides certain risk management capabilities to you – the Project or Portfolio Manager.
After completing my CHAMP certification, I wanted to take Agile to the next level. The CIPSA journey gave me the tools and confidence to scale Scrum and Kanban across teams, making me a stronger planning professional.
Introduction
Before starting the CIPSA certification, I had already gone through the CHAMP journey with Satya, and it gave me a strong foundation with MS Project Agile.
Naturally, my next step was to expand my knowledge into scaling frameworks, and the CIPSA certification felt like the right choice.
It wasn’t just about adding another certificate — I wanted to really understand how to apply scaling with Scrum and Kanban, using practical MS Project Agile tools. The fact that it’s a niche and credible certification made it even more appealing.
Own Study – CIPSA Certification
To prepare, I dedicated daily time in the evenings after work and weekends. On average, I studied 1–2 hours per day, and I followed a roadmap similar to CHAMP:
Watching the videos in sequence
Reviewing handouts and exercises
Going through the .mpp solution files
Revisiting tricky topics until they made sense
Overall, it took me about 6–7 weeks of consistent study. I also took mock exams which helped me gauge my readiness and highlighted weak areas I had to revisit.
“The mock exam was a game changer — it showed me exactly where I stood and what I needed to focus on.”
The course material is very detailed, and the videos are short and clear — which makes it easier to digest. The lesson-end questions were especially helpful in making sure I really understood each topic before moving forward.
Review – CIPSA Certification Course
This course is niche and unique, just like CHAMP certification course, but it goes deeper into scaling Scrum and Kanban. The USP of the course is how it takes you from single-team agile to scaled environments, and all of it is tied back to MS Project Agile views.
The topics that helped me most were:
Scaled Scrum (especially Sprint Planning, Reviews, Retrospectives at CIPSA level)
Resource management and over-allocations in scaled projects
The exercises and solution files were a big plus — you can follow along, check your own work, and immediately see how theory applies in MS Project.
The solution files were invaluable — they helped me bridge the gap between theory and practical application.
CIPSA Exam Experience
I scheduled the exam once I felt confident with the mocks. The exam has 40 questions in 1 hour, and my strategy was simple:
Read carefully, don’t rush.
Mark tricky ones, come back later.
Watch out for trap questions that mix Scaled Scrum vs. Scaled Kanban events.
The exam standard is tough but fair. In the exam, questions included graphs, burndowns, CFDs, situational problem-solving, and some tricky overlaps between scaled Scrum and scaled Kanban.
When I got my result and saw I had passed, it was a huge relief. The evaluation report and certificate came through soon after, which made it all feel real.
Suggestions for CIPSA Aspirants
Dos:
Be consistent with daily study, even if it’s just an hour.
Do every exercise file — they make the difference between knowing theory and applying it.
Use the mocks to spot weak areas and go back to the lessons.
Don’ts:
Don’t skip the scaled Kanban videos — they are equally important as the Scrum ones.
Don’t assume CHAMP knowledge alone will carry you through; this course builds on it but goes much further.
Don’t underestimate reporting questions — they will come.
Conclusion
The CIPSA certification has given me a solid understanding of scaling frameworks and how to apply them using MS Project Agile. I can now confidently guide teams and managers on both Scrum and Kanban at scale.
“CIPSA is not just another certificate — it’s a niche, high-value skill that is already making a difference in my role.”
This certification is not just another “add-on” — it’s a niche, high-value skill that has already started helping me in my professional role. I plan to keep applying these learnings in my day-to-day projects and use them to drive real delivery improvements.
Brief Profile: Ravi O’Reilly, CIPSA, CHAMP
Programme Planning Manager, working in UK Government programmes across Transport, Civil Engineering, and IT, with a focus on applying industry best practices and planning standards.
As I frequently interact with PMP aspirants, I bring this point on the similarities between Stakeholder Management and Risk Management. Few PMPs have written their PMP Success Stories (usually less than 5% write), and they know these differences. Some even have noted the importance of these two knowledge areas:
Stakeholder Management, and
Risk Management.
Do note that, in my classes and courses, I've called Stakeholder Management and Communication Management as the Twins. See herefor a detailed understanding.
I've also said Resource Management is the close Sibling of the Stakeholder Management. Learn more here.
Such terms are mine and I've used it while explaining various such areas for your PMP exam. See here.
In this post, I'm saying that both Stakeholder and Risk Management have a shared language in the Art of Project Management. Like the twins and siblings before, you’d be hearing it for the first time!
Indeed, the language understanding and similarities in both these management areas is unique. As a management practitioner, you need to know them. So, let's see them one by one.
Note: If you are preparing for the Portfolio Management Professional (PfMP) exam, it's good to know the below ones. Stakeholder management will be part of Communication Management knowledge area for your PfMP exam. See here.
1. Identification of Stakeholders and Risks
Stakeholders are identified, so are Risks. Stakeholder identification happens from the very beginning of the project. In fact, the Project Charter (see here) has the initial list of stakeholders and based on it a detailed stakeholder list is prepared.
Risk identification also happens from the very beginning of the project. Like stakeholders, the project charter has high-level information on project risks.
2. Iterative and Integrative Processes
Many think that after a complete identification and assessment has been done, then the process is no longer used. In reality, both stakeholders and risks change throughout the life cycle of the project.
Stakeholder identification is continuous in nature and it's an iterative process. As and when new stakeholders are identified, they have to be assessed, analyzed and engaged. Risk identification too is a continuous process and is iterative in nature.
3. Outputs of Stakeholder and Risk Identification
Stakeholder Register is the key output of the stakeholder identification process. In the real-world, it can be a document or a spreadsheet. It'll have identification, assessment information and stakeholder classification such as being internal or external.
Similarly, Risk Register is the main output of the risk identification process. Again, in the real-world, it's usually a spreadsheet with various risk attributes including the risk id, name, description, probability, impact and risk score. A simple risk register shown below.
4. Outcomes of Stakeholder and Risk Identification
Do note that, I've mentioned outcomes, not outputs. Output is about the end result. Outcome, on the other hand, is about what you actually want to do/have with that end result.
For example, buying a vehicle is an output of the buying process. But using that vehicle to save time or function more efficiently is the outcome. So, how about the outcomes in Stakeholder and Risk Management?
The stakeholder register is the output. Better stakeholder engagement and stakeholder satisfactions are the outcomes. Similarly, the risk register is the output. On the other hand, credible risk management and optimization of risk responses can be the outcomes.
5. Minimization of Negative Impacts
Here, I'm referring to the minimization of potential negative impacts.
Stakeholders can be an individual, a group, a community, or even an organization that may affect, be affected by, or perceive to be affected by a project. In other words, they can impact or affect in a positive or negative way. It's the job of the project manager to minimize the negative impact.
Similarly, the definition of risk (see here) clearly states that a risk can have positive or negative impact on the objectives of the project. Again, it's the job of the project manager to minimize the negative impact of a negative risk (or threat). This is shown below.
6. Maximization of Positive Impacts
This is the reverse of the previous point. I'm referring to the maximization of potential positive impacts.
Risks can be opportunities as well. Opportunities lead to benefits. In risk management, we try to maximize the positive impact of the opportunities, i.e., we try to increase the probability and/or the impact of the risk. For this purpose, risk responses are employed. See here.
Similarly, in stakeholder engagement, the focus is to effectively engage stakeholders- especially with high power and interest or influence. This can increase the chance of project success and subsequent outcomes/benefits.
For example, for the below figure, I've taken two attributes - influence and impact. We want to have the stakeholders to move into high influence (HInf) and high impact (HImp) zone.
7. Stakeholder Engagement Plan and Risk Management Plan
To manage stakeholders, we create the Stakeholder Engagement Plan (SEP). Similarly, to manage risks, we create the Risk Management Plan (RMP). Both these plans are subsidiary plans of the project management plan.
Both these plans are progressively elaborated and integrated into the consolidated project management plan.
8. Hidden Stakeholders and Hidden Risks
While stakeholder identification should be exhaustive and continuous, still it's possible that some can remain hidden. Sometimes, these hidden stakeholders, if not identified and engaged, can derail your project. You need to be very careful in such situations.
Similarly, some risks can remain hidden and may not be identified. There are many ways to identify such risks such as assumption analysis, risk analytics, among others.
9. Stakeholder Attributes and Risk Attributes
Stakeholder attributes such power, interest change. Risk attributes such as probability and impact also change. These are rarely static.
As they change, you’ve to adjust your plans and documents to reflect the changes. For example, a neutral stakeholder can become supportive or resistant over time. In such cases, the engagement strategy has to change.
Similarly, a risk with high probability and high impact can become low probability and medium impact over time. This results in reduction in risk score and the risk could move into the Watch-List.
10. Obsolete Risks and Dormant Stakeholders
Risks are not always active and primary ones. They can be:
Obsolete
Dormant
Secondary
Residual, among others.
When a risk becomes obsolete, they are no longer tracked and are usually marked as closed in the risk register. These can later become part of the organization's archives and can be revisited when needed.
Similarly, stakeholders are not always active and/or primary. As noted earlier, stakeholders' power, influence, interest etc. change over time during the project life cycle. Some stakeholders get passive or even dormant. You need not actively engage with these stakeholders.
With it, you'll learn more. Considering the similarities in the language, here are a few more:
Stakeholders are prioritized, so are risks.
Stakeholders are analyzed. Risk are also analyzed.
Stakeholder engagement levels are monitored; risks are also monitored.
A number of PMPs have used this course to get certified. You can be a PMP too. More importantly, you'll know various areas of project management, which no one can or will be able to tell you.
Hybrid-Agile projects are different – in fact quite different from the traditional waterfall ones or the Agile ones. It combines both waterfall and Agile, but your thought process, mindset and application will be different.
In fact, going further, I'd say that your mindset and thought process must be different as you manage both traditional and agile parts together in a single project. It's not easy and hence, there is a dedicated certification (CHAMP) for it. See here.
Below are some common mistakes to avoid when tracking Hybrid-Agile projects. In addition, avoidance such mistakes or pitfalls can give you right data and hence reports.
Pitfall – 1: Not Setting the Status Date.
While tracking, setting a status date is a must. Many forget to do it, and I’ve seen it repeatedly. In the CHAMP certification course, I’ve emphasized it frequently.
It takes a matter of seconds to set the status or data date, and that makes tracking systematic.
Pitfall – 2: Not differentiating Traditional and Agile Tasks.
As you proceed with a Hybrid-Agile project, you are likely to have thousands of tasks to be managed by a number of resources—human, physical, asset, material, among others.
It’s always good practice to clearly differentiate and segregate such tasks. Later on, when you manage and report, it’ll prove to be immensely valuable.
Pitfall – 3: Not using the Planning Boards.
If you’re using Scrum to follow Agile in Hybrid-Agile projects, there will definitely be a Sprint Planning Board. If the software tool doesn’t provide it, then don’t use that tool.
Now, when you don’t use the Sprint Planning Board(s) but directly update the tasks in the Gantt Chart view, you’ll face a number of problems. For example, you won’t get the data properly updated, including the Board Status!
Note:For Hybrid-Kanban, the creation, usage, and management of boards will be different. Similarly, for Hybrid-Scrumban, the management will be different.
Pitfall – 4: Not Customizing the Board States.
This is another mistake you must avoid. If you have five workflow states, then use five on the boards. If you have three, then clearly segregate and use them on the boards. Have them, but don’t overcomplicate it.
Boards have other uses, such as linking states with % Complete values, reporting, and of course, clear visualization.
Pitfall – 5: Not Using the Visual Indicators and Bars.
Visual indicators and bars are given for your benefit. A large number of visual indicators and bars should be available while tracking. MS Project Agile, which is specifically used in CHAMP, has a large number of them. Other software tools such as Primavera P6 also provide them, though P6 doesn’t support Agile.
When you have visual indicators, bars, and boards, use them abundantly.
Pitfall – 6: Not Baselining the Hybrid Project.
Baselining is needed for traditional project management. Without baselining, there is no mathematical way to know the progress. And nobody can really dispute pure mathematics.
However, for the Agile part, you may not need baselining, except when mandated.
Do note that the baselining part is quite tricky. It becomes trickier when multiple baselines are involved. You’ve to be very careful in this regard.
Pitfall – 7: Not Tracking Variances for Traditional Parts.
Variance tracking and analysis are part and parcel of Waterfall projects. You’ve to do it and also do the reporting. This is linked to baselining, which has to be clearly and consciously done.
Agile elements with iterations, however, need not have variance tracking, except where customer or regulatory requirements mandate it.
Pitfall – 8: Not Having the Right Team Structure.
One of the key ingredients of a project’s delivery success is the team structure. The team structure should be clear with little hierarchy. And you must keep in mind the way delivery happens in traditional and Agile approaches.
Pitfall – 9: Not Following the Principles of Hybrid-Agile Management.
Principles are very important to be followed in any approach. The CHAMP course informs this explicitly. In fact, I’ve published two articles in this regard. You can read them here and here.
Pitfall – 10: Not Using a Combined View.
A combined view consisting of both the traditional and Agile parts is a powerful one. But many don’t know how to use it! This view gives a snapshot of the entire project in a quick time. Of course, it requires proficiency to track in such ways.
The CHAMP certification (see here) uses these views frequently and demonstrates them with a large number of practical exercises with solution files, so that you can master them.
The Certified Hybrid-Agile Master Professional (CHAMP) courseis highly practical as informed and written by many successful CHAMPs. It's also highly economical. As a matter of fact, it's world's only Practical Hybrid-Agile certification, where you learn hybrid-agile management with your own hands.
The below unique trailer (1m: 14s) informs more. For the best experience, go full-screen HD mode and plug-in your headphones.
A brief tabular differentiation between CHAMP and other certifications is shown below.
To know more about the CHAMP certification course, see here.
To have the complete course breakdown, check here.
For this course, many FAQs have been answered. See here.
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).
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 Planningmeeting, 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 replacesthe 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 arecurring 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.
.png)
.png)
.png)
