Agile on the Fly! Mastering Real-Time Sprint Operations with MS Project Agile (2)

In the first part of this article (read here), we understood the following:

• Our Current Sprint State
• Performing Activate/Inactivate Operation
• Performing Delete Operation
• Performing Add Operation

In this part, we will check certain additional operations, which are crucial as you manage your Sprint hands-on. There are many other operations, which you - the Scrum Master or Product Owner - have to perform in your Scrum project. Detailed, hands-on videos are part of the Mastering MS Project Agile course. See here.

We will start with the modify operation. 

Performing Modify Operation

As you proceed with your Sprint, you are also likely to perform several edit or modify operations, such as duration, resources, start date, and end date, among others. This can be done by simply double-clicking on the Card (work item) in the Current Sprint Planning Board view and changing the necessary fields. 

As shown for the featured item of Create a new user, I first double-clicked on the corresponding card, and then I can change the resources in the popped-up Task Information dialog box. You can change multiple fields with this option. 

You can also select the card, right-click and choose the Information option from the drop-down list to see the Task Information dialog box. 

Performing Move Operation

Not every work item included in the Current Sprint will be completed. It’s highly possible that some of the items are not started or are partially complete. In such a case, the items are to be moved into the next Sprint. This is one of the rules in the Scrum framework (see here). Note that the incomplete feature items don’t count toward velocity (see here). 

To move a work item into the next Sprint, again you can use the Current Sprint Board view. Select the work item (Card) and use the Move to Next Sprint command from the list. 

When you use this command, the item will be moved into the immediate next Sprint, not any other! To be sure, you can verify it in the Sprint Planning Sheet view, which is for all the Sprints in the project. Keep in mind that once a work item is complete, it won’t be visible in the Current Sprint Board or Current Sprint Sheet view. This is because of the Sprint Planning Filter (see here).  

As shown in the above figure, the feature Edit an existing user is now part of Sprint 2. Earlier, it was part of Sprint 1.

As it’s moved into the next immediate Sprint, the board status is maintained as Next up. The % Complete value for this work item will also be preserved. Your team can work on this item in the next Sprint. 

Performing % Complete Change Operation

While the % Complete mapping is done for the various workflow states in the Board, it’s not written on stone. For example, in our case the % Complete Mapping is %, 10%, 50%, and 100% for Sprint Backlog, Next up, In progress and Done, respectively. 

It’s possible that you may want to change this % Complete for a particular work item. This can be done by opening the Task Information dialog box and changing the % Complete value in the General tab. This is shown below. 

As shown, for the work item, I’ve changed the % Complete to 20%, in place of the default 10%. You can cross-check this % complete update in the Current Sprint Sheet view.  

While you changed the % Complete value to 20%, notice that the Board Status is not changed, and it still remains in the Next up workflow state.

Demonstration and Key Points

Now, let’s demonstrate what we have learned so far, along with some key points to remember while adjusting a Sprint in progress. I’ve prepared the below video [duration: 5m: 29s] for this purpose. For the best experience, you may want to go full screen in HD mode and plug in your earphones.

Conclusion

In some of the cases, it’s possible that while performing these operations, resources may be overallocated. You can quickly solve overallocation using the Team Planner view available with MS Project Online Desktop client, which has the Agile features.

Projects, like human beings, are living entities. Just as every human being changes, so does a project. If the environment is high-churn, then humans must rapidly adapt and adopt, and so does a Sprint project.

This article outlines certain key operations to adjust a Sprint project. I hope it gives you the understanding to perform various operations within a Sprint, the confidence to conduct any operation in a Scrum project, and brings value to your work.

--

This article was first published by MPUG on March 14, 2023. This an updated version. 

References

[1] Online Course: Practical Scrum using MS Project Agile, by MPUG.com

[2] Online Course: Mastering MS Project 2019 Agile (Scrum and Kanban), by ManagementYogi.com

[3] Certification Course: Certified Hybrid-Agile Master Professional (CHAMP), by ManagementYogi.com 

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

Agile on the Fly! Mastering Real-Time Sprint Operations with MS Project Agile (1)

A Sprint is a mini-project within a larger Scrum project, and it's usually timeboxed for two to four weeks. Though timeboxed, a number of things can change within these weeks. In fact, adjustment of a Sprint in progress is the norm, not the exception. 

In an environment with rapid changes (see here) in requirements and technological uncertainties, a number of areas such as scope, resources, risk, and even business priorities may change. Agile/Scrum, after all, is all about change. In fact, one of the principles in the Agile manifesto states: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Note: The content of this article has been taken from Mastering MS Project Agile course. See here. It's world's only hands-on, in-depth course to master MS Project Agile.

For a project executed in Agile mode, one can have the following:

• Addition, removal, or modification of work items within a Sprint, i.e., changes to the Sprint Backlog.
• Refinement of Release Plan (see here for release planning), i.e., change in features for the Sprints within a Release.
• Refinement of the (Product) Backlog (see here), i.e., addition, removal, movement, or replacement of backlog items, which can be features or stories.
• Rolling-wave planning (see here) for upcoming Sprints, as the current Sprint draws to a closure, among others.

In this article, we will specifically learn how to adjust a Sprint which is in progress. We will see the following real-time Sprint operations:

• Activate/Inactive Operation
• Delete Operation
• Add Operation
• Modify Operation
• Move Operation
• % Complete Change Operation

If you’re working hands-on with MS Project to manage your Scrum project, these operations are vital to know. So, let's start with our Current Sprint State.

Current Sprint State – Timeline View

The current situation for our Sprint is shown in the Timeline view of MS Project Agile. Our Sprint is of two weeks duration from September 11, 2023 to September 24, 2023.

As shown in the above figure:

• There are 3 items to be delivered: Login to the online trading system, Create a new user, and Edit an existing user, which are 50%, 50%, and 10% complete, respectively.
• The Sprint event of Sprint 1 Planning is 100% complete, along with four Daily Scrums. These are indicated with a tick mark for the events.
• Our status date is September 18, 2023, which is one week after the Sprint begins on September 11, 2023.

As we proceed, we will perform several operations. These are important to know if you are really working in a Project with multiple Sprints. As any real-world Agile practitioner would tell you, all these operations may happen.  

However, before you proceed, there are important instructions you need to know before starting, which are mentioned in the below video [duration: 2m:38s].

Next, let's us see our current Sprint board to understand the status date and various workflow items available in respective workflow states.

Current Sprint State – Current Sprint Board 

The current situation for our Sprint is shown in the Current Sprint Board view. 

As shown, several items are either complete (shown with a tick mark on the Cards) or progressed as on the status date, i.e., one week into the Sprint. 

The % Complete of features and Scrum events for the entire Sprint can be seen in the below Current Sprint Sheet view. You have to add this column.

As shown above:

• The features Login to the online trading system and Create a new user are 50% complete, whereas the feature Edit an existing user is 10% complete. 
• A number of Daily Scrums are complete.
• The Sprint Planning event is also complete.

Now, we will proceed with various operations.

Performing Activate/Inactivate Operation

When you try to inactivate a task in any column state, except in the Sprint Backlog state, MS Project software won’t allow it to function! The reason is simple – you can’t inactivate a work item, which is activated and in progress.  

A work item (or task) can be inactivated by going to the Task tab, then Schedule group, and using the Inactivate command. It’s highlighted in the below figure. 

Now you may be wondering how to inactive such a work item. You have to take it back to the Sprint Backlog state to inactivate. This can be done either in the Current Sprint Planning Board or the Current Sprint Planning Sheet view. 

As you can see, the work item is inactivated because of the column state (Sprint Backlog), and the % completion. 

Performing Delete Operation

While you can’t inactivate an in-progress task, you are allowed to delete it. You can do so by selecting the work item in the column (workflow) state, right-clicking and using the Delete Task command. This is shown below. 

But then the MS Project software will pop up a soft message for you, unlike the hard message shown for inactivation we saw earlier.   

As shown for the selected feature item of Edit an existing user, when the delete command is pressed, a message pops up. This message wants you to confirm that you really want to delete it. 

If you proceed, the work item will be fully removed from all the views. In other words, the backend database completely removes the work item. Hence, be careful! 

Performing Add Operation

This is another operation that MS Project Agile practitioners use. While scope addition during the Sprint is not encouraged, it’s very likely to happen in the real world. Even though you may not want your scope to expand, new tasks related to a feature might come up anyway, and those must be added. 

You can add a new task by going to the Current Sprint Sheet view, right-clicking, and using the Insert Task command. Notice that as you add a new work item, the default Board Status used will be Sprint Backlog. 

You can also add the new work items using the Gantt Chart view or the using the New Task command of the Current Sprint Board view. After you add a new work item and associate the resources (see here) to it, it can be properly visualized in the Current Sprint Board view with the needed fields. This is depicted below.

This article continues into part 2. See here.

In the next part, we have additional operations for a Sprint in progress. 

References

[1] Online Course: Practical Scrum using MS Project Agile, by MPUG.com

[2] Online Course: Mastering MS Project 2019 Agile (Scrum and Kanban), by ManagementYogi.com

[3] Certification Course: Certified Hybrid-Agile Master Professional (CHAMP), by ManagementYogi.com 

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

Webinar Series: Scrum at Scale with Hands-on Practical Applicability

In a recent article for Scrum at Scale – CIPSA Key Roles and Goals, I wrote about the power of simplicity. I also said simple is beautiful and simplicity sticks. It's applicable in all walks of our lives. You can read it here.

Simple people are liked more, trusted more. Simple things are easily remembered and hence followed. Simple, elegant dresses are natural and indeed, beautiful. Simple manners, for example just a simple and genuine 'thank you' goes a long way many times with the right people in the right environment. 

In any human endeavor, simplicity is a powerful tool. A simple message is more effective and efficient than a long, complicated message. A simple person or organization is easier to work with than a complicated one. However, to make things simple is not that simple. In fact, it' very hard, long-drawn and has to be cultivated. 

The Certified In Practical Scaled Agile (CIPSA) framework strives to be simple. I believe it's the simplest possible framework for Agile at Scale in the world. In addition, it's the only practical Scaled Agile framework in the world.

As shown above, the CIPSA Scrum Framework extends team-level Scrum in a minimal possible way. There are no layers and layers of backlogs, layers and layers of roles and events. If you read the CIPSA Guide – free to download and use, you’d immediately notice these:

• The roles are just two.
• The goals are just two.
• The events are just a few.
• The artifacts are just three.

Considering multiple Individual Scrum Teams and agile at scale, it’s a simple, yet powerful framework. If you know the Scrum approach, you’ll understand quickly understand the CIPSA Scrum Framework. In addition, the CIPSA framework can use any software tool, including MS Project Agile. 

In my upcoming webinar series conducted by Master Projects for Unlimited Growth (MPUG), you’ll learn about scaling, aspects of scaling, other scaling frameworks, the CIPSA Framework (specifically the CIPSA Scrum Framework), various parts of the framework and more. In the final part, we will also see practical, hands-on demonstrations. 

Join me in these three-part webinar series to know more on Scrum at Scale using the CIPSA Framework. The links are noted below. Registration is closed. 

Below are the event details.

Part - 1: Understanding Scaling with Scrum

• Date: March 12, 2025
• Time: 12:00 PM - 1:00 PM ET, US
  09:30 PM - 10:30 PM, IST, India
• Event Brief: https://mpug.com/event/scaling-scrum-with-hands-on-applicability-understanding-scaling-with-scrum-part-1/

Part - 2: Scrum at Scale with the CIPSA Framework

• Date: March 19, 2025
• Time: 12:00 PM - 1:00 PM ET, US
  09:30 PM - 10:30 PM, IST, India
• Event Brief: https://mpug.com/event/scaling-scrum-with-hands-on-applicability-scaled-scrum-with-cipsa-framework-part-2/

Part - 3: Scrum at Scale with CIPSA and MS Project Agile

• Date: March 26, 2025
• Time: 12:00 PM - 1:00 PM ET, US
  09:30 PM - 10:30 PM, IST, India
• Event Brief: https://mpug.com/event/scaling-scrum-with-hands-on-applicability-hands-on-scaled-scrum-with-ms-project-part-3/

Note: You need not have in-depth knowledge of Scrum to understand Scrum at Scale with CIPSA. Also, if you don’t know anything at all about Scrum, you can join, too. We will have a brief discussion on Scrum. 

If you have missed Part 1 of the series, a summary is here.

--

The contents of this webinar series are taken from Certified In Practical Scaled Agile (CIPSA) course . This is the only practical, hands-on, scaled-agile certification course in the world.

References

[1] New Practical Scaled Agile Framework - The CIPSA Framework, by Satya Narayan Dash

[2] Understanding the CIPSA Scrum Framework, by Satya Narayan Dash

[3] Certified In Practical Scaled Agile (CIPSA) course, by ManagementYogi.com

Practical Scaled Agile (CIPSA) Certification: 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] *NEW* Certification Course: Certified In Practical Scaled Agile (CIPSA), by Satya Narayan Dash

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

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

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

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

New Practical Scaled Agile Framework – The CIPSA Framework

I’m pleased to announce the availability of ManagementYogi's Practical Scaled Agile Framework. The  Certified In Practical Scaled Agile (CIPSA) certification course is based on this framework. With CIPSA (sip-sa), you can scale to multiple Scrum or Kanban teams and deliver complex products or solutions.

It's the only framework and certification in the world, which informs how to scale with software tool(s). It's practical and hands-on. No other framework and/or certification course in the world provides it!

The Practical Scaled Agile framework has been under development since March of this year. It has gone through multiple iterations, a number of prototypes with reviews and article publication before it’s made public today. 

Why Non-Practical, Scaled Agile Frameworks are Ineffective?

Worldwide, a number of Scaled Agile frameworks are available. Unfortunately, not a single one of them informs how to do scaling in a practical, hands-on manner with software tool(s). This, indeed, is a big problem. Many Scaled Agile Practitioners, with whom I frequently interact, really don't know how to do scaling in the real-world as they are certified in theories.

For example, considering multiple Scrum teams sprinting together or multiple Kanban teams working together on a Product Backlog, a number of questions come-up:

1. How do you to manage so many Sprints across multiple Scrum teams?
2. How do you synchronize multiple Sprints in a cross-team environment?
3. If Kanban is used at the team level, how would you scale?
4. Can you track multiple teams (say five Scrum or Kanban teams) together at scale?
5. Is it possible to see burndown/burnup charts for the entire scaled team and individual teams?

With ManagementYogi's Practical Scaled Agile framework, the answers to all the above questions are in affirmative – yes all of them! In addition, you can manage all the teams using a single software tool, which in our case is MS Project Agile. You can also manage assignment, planning, tracking, stands-ups, retros and reviews at scale. 

With this background, let me introduce the framework used for the Certified In Practical Scaled Agile (CIPSA) course. As our Practical Scaled Agile framework is directly associated with the CIPSA certification, going forward, I’ll call it CIPSA framework.

The CIPSA Framework

The CIPSA framework extends the team level Scrum or Kanban, helps to solve dependencies and enables collaboration and cross-team management. It extends them in the following ways. 

CIPSA Artifacts: All individual teams use a single and same Product Backlog. The Product Backlog items are visible to all the teams, but items are distributed across the teams. This backlog goes through refinement so that the individual teams can know which items to work upon in the next Sprint (Scrum) or Release (Kanban).

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

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

CIPSA Events: There are multiple events in the CIPSA framework, namely, CIPSA Backlog Refinement, CIPSA Planning, CIPSA Daily Stand-up, CIPSA Review and CIPSA Retrospective. Each of these events plays a critical role in managing Agile at scale. 

CIPSA Roles: There are two primarily roles in CIPSA complementing the accountabilities at the individual team level. They are Chief Product Owner and Principal Scrum Master (Scrum) or Principal Flow Master (Kanban).

At the individual Team level, there will be Product Owner, Scrum Master (or Flow Master) and Developers, some of whom play a major role in integration work. There is no separate integration team because developers are encouraged to be generalizing-specialists.

The CIPSA Framework – Graphical

The CIPSA framework is shown in the below figure. It shows the CIPSA artifacts and CIPSA events at scale. It also shows the artifacts and events at an individual team level, in dotted rectangles and circle.

The CIPSA Framework – Interactions

There is a single Product Backlog with ordered items and it’s continuously refined with cross-team members as part of the Cross-Team Backlog Refinement meta-event. The Product Backlog with the Product Goal is presented in the CIPSA Planning meta-event by the Chief Product Owner to the CIPSA team. In this meeting, a CIPSA Backlog is created with the Product Backlog items that can be delivered by multiple teams in the upcoming Sprint (Scrum) or Release (Kanban). In other words, the “what” part is decided here.

Post CIPSA Planning meeting, for each team, an individual Team Planning event takes place. The Product Backlog items taken for the respective team is broken down into individual tasks, which results in Team Backlog. A Team Backlog is available for every team. In other words, the “how” part is decided here. 

Next, each team begins to work on the respective Team Backlog. A CIPSA Daily Stand-up meeting happens everyday with cross-team members to synchronize the work, identify cross-team dependencies, issues and risks. The CIPSA Daily Stand-up is preceded by Individual Daily Stand-ups for the individual teams. 

In the CIPSA Review meta-event, a CIPSA Integrated Increment is presented for the entire CIPSA team and needed stakeholders. As the focus is on CIPSA Integrated Increment, CIPSA Review meeting replaces the individual Team Reviews. 

In the last meta-event of CIPSA Retrospective, the CIPSA team reflects on the effectiveness of the CIPSA team as a whole and determines the improvements that can be taken-up. The CIPSA Retrospective is preceded by Team Retrospectives, which are specific to the individual teams. 

The below video [duration: 7m] explains more on this new CIPSA Framework. 

 

Conclusion

As you’d have noticed, at the team level in CIPSA, one can use either Scrum or Kanban, while most Agile at Scale frameworks take only one. Also, quite a few scaled Agile frameworks employ a large number of artifacts (also events or ceremonies and roles), which are in violation of one of the four values of Agile Manifesto: 

"Working software or product over comprehensive documentation."

Above all, not a single Scaled Agile framework informs how to do scaling in a practical, hands-on manner. 

As we just saw with the figure and explained interactions, the CIPSA framework is simple to follow and you can employ it in your organization or teams. And you can do the entire scaling with the hands-on software tool of MS Project Agile.  

The CIPSA framework is free to use. However, when you use this framework or the concepts from this framework, I’d expect you to give due credit.

The detailed CIPSA framework guide is now available (August 30, 2024). The guide is free to download and use. The new CIPSA Certification Course is based on this framework.

References

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

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

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

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

Sprints at Scale: Working with 10, 100, 1000, or More Sprints in A Scrum Project

A Sprint is a mini-project and usually has a length of 2 weeks, though it can vary from 1 to 4 weeks. While running Sprints for a big project using Scrum framework, one can run 10, 100, 1000, or more Sprints. The number of Sprints goes-up when the Sprint length is shorter – say 1 week. This scenario highly possible.

Do not confuse Sprints at Scale with Agile at Scale, where multiple teams can work on multiple Sprints.

Now, questions can be:

• How do you manage so many Sprints?
• If you are using a software tool, how do you manage them?
• Is it possible to have the current Sprint being shown first in the tool?
  (with all other Sprints)
• Is it possible to show the work items for the current Sprint first?
  (a view showing all the Sprints)

These questions are very pertinent for any Scrum Master, Product Owner or an Agile Project Manager. In fact, recently I received such questions from Agile practitioners, who have been using my courses.

Let’s see how to manage a large number of Sprints and the answers to the above questions. 

Our Plan with Epics and Features

Our current plan is shown below and at a high-level:

• There are 5 epics, from Epic 1 to Epic 5.
• Each epic is broken into 10 features. In total, there are 50 features.
• These features will be associated with the respective Sprints. 
• One feature will be completed in one Sprint. For example, feature 50 will be done in Sprint 50. 

This is shown below in the Gantt Chart view of MS Project. 

These you can add in the Gantt Chart view or you can use the Sprint Planning Board or Sprint Planning Sheet views. 

As shown, we have features numbering up-to Feature 50. When you switch to the Sprint Planning Sheet, you will get the following view. 

Plan for the Sprints

To associate with Sprints, we need to create the Sprints first. These can be done using Project tab > Properties group > Manage Sprints command. 

As you can see, we have 50 Sprints planned now. 

Associate with the Sprints

One can use various possible views to associate the feature items with Sprint, but the most used ones (and recommended by my courses) are the Sprint Planning Board and Sprint Planning Sheet views of MS Project Agile software tool.

Using the Sprint Planning Board, for example, I’ve associated a number of features items as shown.

You have to simply drag and drop the items from the No Sprint column to the respective Sprint column. But then we have some constraints here!

• When it reaches Sprint 5, then the board view on the left does not show the feature items. If you have to associate with Sprint 50, then you have to drag it all the way up-to Sprint 50, which is on the extreme right.
• If you want to see only the last 3 Sprint items, i.e., Sprint 48, Sprint 49 and Sprint 50, then we also have to use the horizontal scrollbar to the end.

Hence, the better view to use in this case of having a large number of Sprints will be the Sprint Planning Sheet view. This is shown below. 

As shown, you have to just scroll down and associate the Sprint in the popped-up, drop-down or show-up list. Isn’t is very easy this way?

Show the Latest 3 Sprint Items first

Another issue is to show the last 3 Sprint items first. This cannot be done using the Sprint Planning Board view as the filters, groups are disabled in this view.

But you can circumvent it using the Sprint Planning Sheet view and applying the built-in Sprint group.  

Do note the change in order from from Ascending to Descending. That way, the latter Sprints will be shown on top. 

Sprint Grouped View

As you apply the above modified Sprint group, you will have the latter Sprints and the associate work items shown on top. The initial Sprints such as Sprint 1, Sprint 3 or Sprint 5, will be shown towards the bottom.  

Another Way to Show

Some of you may not want to apply to the Sprint group, but just want to see the latter Sprint items on top for quick usage. In that case, you have to change the sorting and sort it by Sprint ID as shown below. 

The Sort command dialog box can be seen by going to View tab > Data group > Sort > Sort By... command. 

Do note the change the order of sorting to Descending. That way, the latter Sprints and associated work items will come on top. 

When you apply this sorting, the Sprint Planning Sheet will come as shown below. 

As shown:

• The work items for Sprint 50, Sprint 49 and Sprint 48 are shown on top.
• The work items for Sprint 1, Sprint 2 etc. are towards the bottom.

In this case, we didn't apply any group, but just sorted items with Sprint ID field.

References

[1] Video Course: Mastering MS Project Agile, by Satya Narayan Dash 

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