ManagementYogi’s Scaled Agile (CIPSA) Certification: Multiple Kanban Teams and Kanban Boards with MSP Agile (2)

In the earlier part, we learned:

• Need of Scaling in an Organization.
• Importance of CIPSA Certification, worlds's only Practical Scaled Agile certification.
• Our Scaled Scenario (Multiple Kanban Teams).
• Scaling the Kanban Teams (using MS Project Agile).

This is the second and concluding part. You can read the earlier part here.

[Part - 1]

--

Scale the Kanban Filters

Our next step is to build custom filters, which will be associated with separate Kanban team boards. These custom filters will have the custom flags enabled for them. The below figure is for Team A Task Board and named as Team A Task Board Tasks Filter.

To create the filter, go to View tab > Data group > Filter > More Filters… command. If you are in the Sheet views for this Scaled Kanban Project, you can select the “Highlight Filter” drop-down list as the default filter option would be disabled.

For the Team A Task Board Tasks shown above:

• Show on Board is enabled.
• Summary (summary tasks) is disabled.
• Team task custom field has the condition fulfilled.

If you want, you can enable the ‘Show in menu’ highlighted above.

Similarly, create two more filters for Team B and Team C as Team B Task Board Tasks filter and Team C Task Board Tasks filter, respectively. You can use the Copy command in the More Filters dialog box to quickly create the filters. After you create all the filters, it can be seen as follows.   

If you have selected the ‘Show in menu’ checkbox while creating the custom filters and it’s a good idea to do so, you can see all the filters under Custom part of the list of available filters. 

Scale the Kanban Tables *** UPDATED ***

In this step, we will create three custom tables and these tables will be applied to the board views that we are going to create. We will learn the steps to create the custom views shortly. To create the tables, go to View tab > Data group > Tables > More Tables… command.  From there create a new table. The below figure is for the Team A Task Board Tasks Table.

As shown:

• The fields are ID, Indicators, % Complete, Work and Board Status.
• If you have used the Copy command to take the elements from the already available Task Board Tasks table (applied to the Task Board view), then remove the Sprint field.

Similarly, create two more tables for Team B and Team C, which are Team B Task Board Tasks Table and Team C Task Board Tasks Table, respectively. Post creation, you will have the tables available under the custom part of Tables drop-down menu. 

Again, though I’ve used the Task Board Sheet view above, you can use either Backlog Sheet or Task Board Sheet view for a Scaled Kanban project. This I’ve explained in my course: Mastering MS Project Agile.

Scale the Kanban Boards

In our final step, we are going to create the Task Board Views for all the teams. To do so, go to View tab > Task Views group > More Views… command. From there, create a new Single View (not a Combination View) from the View Definition dialog box. 

• The view name is Team A Task Board.
• The screen used for this view is the Task Board.
• The filter applied is Team A Task Board Tasks Filter.

Similarly, create two more Task Board views. For Team B, it’ll be Team B Task Board view and for Team C, it’ll be Team C Task Board view. Next, when you assign resources to the tasks and apply the view, the following one comes up, which is for Team C.

Did you notice Team name (Team C) has been highlighted in the cards above? That’s another advantage you can have in Scaled Kanban Projects with MS Project Agile!

For more detailed tracking in sheet views, one can create individual sheet views (e.g., Team A Task Board Sheet view) for each team. Such views can be created in a similar manner as we have created the board views.

Demonstration: Scaled Kanban – Hands-on, Practical

Let’s have a demonstration of what we have learned so far with our practical scaled approach using Kanban to deliver a product or service. The below video [duration: 6m:50s] demonstrates scaling with MS Project Agile. Do not forget to go full-screen HD mode and to plug-in your earphones.

The content of this video has been taken from the Certified In Practical Scaled Agile (CIPSA) course.

Conclusion *** UPDATED ***

Pause for a moment…

Go back 900 years in time and imagine what it would have taken to build something like the Konark Sun Temple with over a thousand craftsmen. The planning, scheduling, tracking and completion would have been a colossal task. But they succeeded.

Remember the 12-year-old kid that we began with?

After completing his work, the young boy jumped into the nearby big ocean giving up his life to protect the reputation of others! Other craftsmen didn’t have the know-how of the final placement of the ‘kalasha’, meaning temple top. But the kid knew and made the supreme sacrifice for his team.

In today’s world, however, with right learning content, certifications and project management software, one can have the know-hows and expertise. As the project manager and hence the leader of your team, many times you plan for and lead multiple Kanban teams, which can be distributed and/or dispersed.

Knowing how to scale definitely helps. As we just learned, MS Project with its Kanban features is eminently capable of scaling to a number of Kanban teams. You can confidently build products or services using the CIPSA Framework, which is based upon Scrum or Kanban features  in MS Project Agile and deliver them at scale in a practical, hands-on manner.

[Part - 1]

This series is concluded.

--

This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away 5 years ago on June 11, 2019. He, along with my mother, Mrs. Bidyut Prava Dash, first narrated the story of Konark Sun Temple to me.

The temple still stands today, nearly 900 years later and is considered to be one of the seven wonders of India. Next to Sanskrit, Odia has the highest number of ancient manuscripts, including construction, among all Indian languages.

--

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

References

[1] *NEW* Certification Course: Certified In Practical Scaled Agile (CIPSA)

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

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

[4] Understanding the CIPSA Kanban Framework – Practical, Hands-on Kanban at Scale

[5] The CIPSA Framework Clock - A Unique Way

ManagementYogi’s Scaled Agile (CIPSA) Certification: Multiple Kanban Teams and Kanban Boards with MSP Agile (1)

  

The ‘black mountain’ forced in,

    broke Konark’s iron gates,

Drank the water of Mahanadi river,

    and ate from the golden plates.

– Narrated by my parents in Odia, loosely translated into English

Growing up, from the above paraphrased poem, I learned of the destruction of Konark Sun Temple in Odisha, India by “Kala-Pahada” (meaning Black Mountain), a person presumably named so for his black deeds. But what inspired and stuck with me is not the destruction of Konark (Kona meaning corner, Arka meaning sun), but its construction.

Destruction is easy, construction is not. Destruction takes minutes, sometimes seconds, but great construction demands tough love, sometimes despair of not knowing the path, but still pursuing the mission. It’s painful, yet beautiful.

The construction of 228-foot-tall Konark sun temple in 13th century was done by 1,200 craftsmen toiling for 12 years to build the monument. A 12-year-old boy, with his knowledge over existing Odia construction manuscripts, gave the final touch to the construction.

Now, any large construction such as the stoneware in Konark, or software as built by engineers, will require scaling. It’s inevitable. This article is about the scaling of teams using the Kanban framework. In this article, we will learn how to build multiple Kanban Boards with the MS Project Agile software tool and how to use these boards across multiple Kanban teams.

To simplify scaling, which is inherently complex, we are going to use the CIPSA framework. The recently launched Certified In Practical Scaled Agile (CIPSA) course uses this framework to manage both Scaled Scrum and Scaled Kanban Projects. Proceeding further with this article, we will use the concepts and examples used in the CIPSA certification course for Scaled Kanban projects.

This is series [Part - 2]

Our Scaled Scenario – Multiple Kanban Teams

We have three separate teams – Team A, Team B, and Team C – working on different Kanban work items for a Home Renovation Project. All the work items are part of a single Kanban Backlog. However, the team visualizations are different. It’s shown below with various teams working on respective items. 

The below video [duration: 5m:25s] prepared in support of this article explains more on the foundational aspects of scaling using Kanban. To get the most out of this article, watch the video before reading the rest of this article. For the best experience, go full-screen HD mode and plug-in your earphones.

The initial plan created for this Scaled Kanban Project is shown below in Task Board Sheet view. Backlog Sheet or Gantt Chart views can also be used to visualize the plan. (click on the image to enlarge)

Each team wants their work to be managed separately to avoid issues with overlapping, resource assignment and tracking. However, there can be dependencies among the work items.

Hence, for each team, we will have individual boards – Team A Task (or Kanban) Board, Team B Task Board, and Team C Task Board. As we have separate boards, we need to have separate filters to segregate the team-specific tasks. Each task added into the overall project plan will have custom fields associated, e.g., if the tasks are for Team A, then they will have associated custom fields.

With this background, let’s proceed and learn how these boards can be used separately by individual teams, Kanban Flow Masters (equivalent to Scrum Masters in Scrum) and Kanban Service Request Managers (equivalent to Product Owners in Scrum) to manage and track the work items.

Scale the Kanban Teams *** UPDATED ***

In our first step, we will create a Team custom field, taking the text custom field for tasks. You can create this field by going to Backlog Sheet (Task Board Sheet) tools > Format tab > Columns group > Custom Fields command > Task custom fields. It also can be done from the Gantt Chart tools.

As shown, we have taken the Text 1 task custom field and renamed it as Team. This custom field will now have a lookup table. The lookup table can be seen by clicking on the Lookup… command button, highlighted above. In the lookup table, will have four values:

• Team A, for tasks assigned to Team A.
• Team B, for tasks assigned to Team B.
• Team C, for tasks assigned to Team B.
• Unknown, for tasks not yet assigned. This will be the default value.

After you have populated the lookup table, it will appear as shown below. Do note that the default one has been highlighted in blue. 

The custom field created must be associated with tasks, e.g., Team A field value will be for tasks which will be executed by Team A. Similarly, for others.

I could have used individual custom Boolean flags for three teams, but then it’s not very efficient. What happens when you have three, five, or nine teams? Are you going to add nine flags? You get the idea!

So, next we will associate these fields with the individual tasks of the Scaled Kanban Project. To associate, simply add the Team custom field as one of the columns in the view and choose the respective team, as depicted below. 

While I’ve used the Backlog Sheet, you can use any other views such as Task Board Sheet, Task Board, or Gantt Chart view. The custom field won’t be available by default as a column in the tabular part of the view, hence you have to add the related column in order to associate.

Note: There will be other scaling involved with respect to the teams. The above one is with respect to the tasks, not the resources. 

--

In the concluding part, we will see the following:

• Scaling of the Filters 
• Scaling of the Tables
• Scaling of the Boards
• Another video demonstration – hands-on, practical

Finally, we will conclude with the importance of using a hands-on, practical certification for Scaled Agile and a CIPSA certified professional. 

[Part - 2]

References

[1] *NEW* Certification Course: Certified In Practical Scaled Agile (CIPSA)

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

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

[4] Understanding the CIPSA Kanban Framework – Practical, Hands-on Kanban at Scale

[5] The CIPSA Framework Clock - A Unique Way

ManagementYogi's Scaled Agile (CIPSA) Certification: Differences – Product Backlog, CIPSA Sprint Backlog and Team Sprint Backlog

Recently, I wrote an article demonstrating Product Backlog, CIPSA Sprint Backlog and Team Sprint Backlog. I also listed out a few differences. In this article, we learn more on these differences for projects using Scrum at Scale and the CIPSA Framework.

I’d strongly recommend that you read the article first here. Alternative link is here.

Now more differences between these backlogs. There can be other differences and by no means these are exhaustive. 

Difference – 1: Creation

The Product Backlog is a single one and stands on its own. The CIPSA Sprint Backlog is prepared from the Product Backlog. The Team Sprint Backlog is prepared from the CIPSA Sprint Backlog.

Difference – 2: Content

The Product Backlog will have the product backlog items. Some of the product backlog items – the high-order ones – will be part of the CIPSA Sprint Backlog. The Team Sprint Backlog will have mostly the tasks which will be executed in the upcoming Sprint.

Difference – 3: Goals

The Product Backlog will have the Product Goal, whereas the CIPS Sprint Backlog will have a CIPSA Sprint Goal. Finally, the Team Sprint Backlog will have the Team Sprint Goal.

Alignment: Related to the goals, we have alignment. The Team Sprint Goal is in alignment with the CIPSA Sprint Goal, whereas the CIPSA Sprint Goal is in alignment with the Product Goal. 

Difference – 4: Dependencies

We don’t note usually note the dependencies in the Product Backlog because is dynamically changing. The inter-team dependencies are usually noted in the CIPSA Sprint Backlog, but the intra-team dependencies will be part of the Team Sprint Backlog.  

Difference – 5: Events and Meta-Events

The Product Backlog doesn’t contain any meta-events. The CIPSA Sprint Backlog will contain meta-events such as CIPSA Sprint Planning, CIPSA Daily Scrums, among others. The Team Sprint Backlog contains team-level Scrum events such as Team Sprint Planning, Team Sprint Retrospectives, among others.

Difference – 6: Ownership

The Product Backlog is owned by the Chief Product Owner (CPO). The CIPSA Sprint Backlog is owned by the entire CIPSA Scrum Team. On the other hand, the Team Sprint Backlogs are owned by the individual Scrum Teams’ Product Owners. 

Difference – 7: Increments 

The CIPSA Integrated Increment comes from the CIPSA Sprint backlog. The individual Team Increments come from the Team Sprint Backlogs. With every integrated increment, we move closer to the Product Goal, which is part of the Product Backlog.

Difference – 8: Lifecycles

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

Difference – 9: Refinement

The Product Backlog is cross-team refined. The CIPSA Sprint Backlog is not cross-team refined. It’s final! Similarly, the Team Sprint Backlog is also not refined. However, there are possibilities of scope changes during the Sprint for both the CIPSA Sprint Backlog and Team Sprint Backlogs. 

Difference – 10: Super- or Sub-sets

The sum of the CIPSA Backlog (considering multiple Sprints) will be a subset of the Product Backlog. The sum of Individual Team Sprint Backlogs will constitute a subset CIPSA Sprint Backlog.

In other words, you can say that the Product Backlog is the super-set, but without the tasks, events, meta-events and other line items. 

The Team Sprint Backlog is the subset of CIPSA Sprint Backlog, but with additional line items. The CIPSA Sprint Backlog is the subset of the Product Backlog with its own line items.

Conclusion

The CIPSA Scrum Framework uses the underlying CIPSA Framework. It’s world’s only Practical Scaled Agile Framework. 

Instead of focusing on theory, theory and more theory, with the CIPSA Certification, you learn how to actually build these backlogs, find out the dependencies, load the resources, solve the overallocations, create a variety of charts or reports, among many others. 

As always, the best time to learn and get certified is now! 

References

[1] *NEW* Certification Course: Certified In Practical Scaled Agile (CIPSA)

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

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

[4] The CIPSA Framework Clock - A Unique Way

[5] Scrum at Scale: Product Backlog, CIPSA Sprint Backlog and Team Sprint Backlog with MS Project Agile

Primavera P6 – Scheduling and Tracking A Level of Effort (LOE) Activity

Here’s is to the Engineers, brave and bold,

Here’s to the Planners, wise and old.

Here’s to the Architects, strong and proud,

Here’s to the Developers, good and loud.

Here’s to the Entrepreneurs, taking the risks,

Here’s to the Managers, making it tick.

The above one is a paraphrased poem, initially written by Todd Rundgren, as per the web (internet). I really liked the poem and used it in the context of real engineers, entrepreneurs, managers and others, who use a wide array of tools, frameworks, and concepts such as Level of Effort (LOE) activity. 

I wrote about the LOE activity earlier and informed how it’s planned. This raised some questions related to scheduling and tracking LOE activities, which some engineers and managers find difficult to use. In this post, we will check the scheduling and tracking aspect of LOE activities.

It’s a good time to remind you that the LOE activity is not like Task or Resource Dependent Activities. 

Planned LOE Activity

Below is the plan for the LOE activity. It’s a simple plan with few activities so that your understanding is easier. (Click on the image to enlarge)

As shown above, we have the following:

• Two milestones – Start and Finish Milestones
• Activity A – Duration of 5 days
• LOE Activity – Duration of 5 days
• The LOE Activity is hanging between the Start and Finish milestones. 

However, note that for the LOE Activity, the predecessor setting should include the Activity A, not just the Finish milestone. 

This also has been scheduled by going to Tools > Schedule … command in the menu. 

Enter the Data and Track

Next, we enter the data. Let’s say our status date is 2 days into the plan, i.e., 06-Oct-27. When I do that, we will have the following view.  

The Progress Spotlight can be seen by setting the Data Date using the Update Progress… command from the Tools toolbar. 

On this Data Date (06-Oct-27), we have the following updates:

• Start milestone is 100% complete.
• Activity A is 50% complete, with 3 days remaining.
• LOE Activity is 50% complete, with 3 days remaining.
• Finish milestone is yet to start.

This is shown below. 

As you can see the LOE Activity is 50% Complete, but the Schedule % Complete is 0%. This is because we have not scheduled. 

Schedule to Check the Progress

Next, we are going to schedule by going to Schedule … command from the Tools toolbar. 

As we schedule, we will get the update on the already entered data. The Schedule % Complete will be different from the Activity % Complete. The latter is dependent on the Duration % Complete, which has been set for all the activities. 

Below is the view for our schedule plan.  

As shown above, for the LOE Activity:

• The Schedule % Complete is 40%, which is correct because 2 days have gone as on the Data Date.
• The Activity % Complete is 50%, which is also correct as it maps to the Duration % Complete.

In addition, there are two important parts in the graphical side of the Gantt Chart. On the Tracked LOE Activity:

• Left part of the activity is blue color coded.
• Right part of the Activity bar is green color coded.

You can visualize this by double-clicking and enlarging the above image.

Video Demonstration

The below video [Duration: 4m, 32s] explains the above steps briefly and demonstrate the usage of a LOE activity. You can go full screen HD and plug-in your earphones for better experience. 

https://www.youtube.com/watch?v=8wZwwsPShIo

Conclusion

It’s not that complicated to understand LOE activities. As noted earlier, these activities are quite useful when you go for the project management plan. Specifically, for management related work, you can have the LOE activity.  

Not all project-portfolio management software tools provide this capability, but Primavera P6 does. So, make good use of it.

References

[1] Article: Level of Effort Activity in Primavera P6, by Satya Narayan Dash

[2] Article: Primavera P6 – Understanding Various Activity Types, by Satya Narayan Dash

[3] Course: Practical RMP with Oracle Primavera Risk Analysis, by Satya Narayan Dash

[4] Course: Practical PMP with Oracle Primavera P6, by Satya Narayan Dash

Level of Effort (LOE) Activity in Primavera P6

The Level of effort (LOE) is one of the activity types in Primavera P6. As noted in the earlier post, it is dependent on its predecessors and/or successors. It can be used in certain scenarios. In this article, we will explore this type of activity hands-on with Primavera P6, compare with the Hammock Activity and conclude with some key points.  

Definition

As per Primavera P6, a Level of Effort activity can be defined as follows:

“If activity's duration is dependent on its predecessor and/or successor activities, then you can indicate that activity to be a Level of Effort activity.”

Re-read the previous line. It may not be a single predecessor and/or successor, but multiple predecessors and/or successors.

We go for LOE activities when we have on-going tasks, which depends on other activities. 

Now, let’s take an example for the creation of Level of Effort activity. 

Create the LOE Activity

To create a LOE activity, add an activity with Activity Type as “Level of Effort”. This is shown below. 

As shown above, we have created an activity:

• Name = Management Work
• Activity Type = Level of Effort
• Duration = 5 days (default)

Set the Bar Style(s)

As you’d have noticed in the graphical side, we don’t have a visualization for the LOE activity. It’s empty. To visualize, we have to set the bar styles. This can be done by going to View menu > Bars command or Layout toolbars > Bars command. You can also put your cursor in the graphical side of the Gantt Chart, right click and choose Bars command.

As shown, we have set the bar for the LOE activity. Do note that there are two bars for LOE activities. 

• Remaining Level of Effort
• Actual Level of Effort

Both should be enabled if you want to track both the planned and actual data related to LOE activities. And all conditions, as shown above, should be properly set. Now it’ll be visible in the graphical side of the Gantt Chart. This is shown below.

Set the Predecessor(s) and Successor(s)

Next, we have to set the predecessor(s) and successor(s) of this activity. Our management work will span across the entire project. Hence, in our case:

• Predecessor is the Start Milestone
• Successor is the Finish Milestone

After you set the milestones, the LOE activity will look as follows.

As can be seen above, the LOE activity is now scheduled between the Start and Finish milestones. Like a Hammock, it looks to be handing between two milestone activities. The LOE activity has:

• A Start-to-Start (SS) relationship with the Start Milestone
• A Finish-to-Finish (FF) relationship with the Finish Milestone

Next, as you schedule with the Primavera P6 software, our LOE activity hangs between these milestones and spans across the entire project. Do note that a LOE activity is similar to Hammock Activity, but not exactly the same. 

Key Points to Note

Following are the key points to note when you go for LOE activities.

• It’s used for on-going tasks such as project management, shift monitoring work, work related to security guards etc. 
• While going for Resource Leveling, the LOE activities are not included!
• Unlike Hammock Activities, the LOE activities use its assigned calendars to summarize the dates.

Conclusion

Specifically, in a project management plan, I'd recommend using the LOE activities for the project management work. Because a PM may not be working on a plan for the entire day, but will be working a few hours on each project. In such cases, you can assign the PM to the LOE activity at a reduced unit/time.

References

[1] Article: Primavera P6 – Understanding Various Activity Types, by Satya Narayan Dash

[2] Course: Practical PMP with Oracle Primavera P6, by Satya Narayan Dash

Primavera P6 – Understanding Various Activity Types

The Primavera P6 software has a number of activity types considering various aspects of project or project-portfolio management. It covers areas such as milestones, WBS related, level of effort (LOE) and the normal ones. In this article, we will understand the activity types available.

The Fundamentals

Each activity (or task in simple terms) must be assigned an activity type. This is because a plan is basically activity driven and as the plan proceeds, we execute the activities. 

Activity types are important because they will control the duration and dates. Taking some examples: 

• When you add more resources to an activity, the duration will be reduced. In project management parlance, it’s called crashing. 
• When you have different calendar associated with an activity, the activity finish date will be impacted.
• When you have resources with different calendars, agian the activity's duration and finish dare will be impacted.

Overall Information

There are six types of activities in Primavera P6:

• Task Dependent activity
• Resource Dependent activity
• Start Milestone activity
• Finish Milestone activity
• Level of Effort (LOE) activity
• WBS Summary activity

This can be seen by going to the bottom half of the Activities window > General tab > Activity Type drop-down menu. (click on the images to enlarge) 

As shown, we have a web-based Information Management System project. The default activity type chosen is the Task Dependent activity for the selected activity. Rest of the activity types are also seen in the drop-down list.

This is the default one because when we create and open a new project within the Primavera Enterprise Project Structure (EPS), we need to set the default activity type. This can be done by going to the bottom-half of the Projects window > Default tab > Activity Type drop-down menu.  

Based on this setting, when you create a new activity, that will be seen in the Activities window. 

Next, let’s see these activity types one by one.

Task Dependent Activity

As explained earlier, this is the default activity type in Primavera P6. 

In this activity, when you assign resources, the scheduling engine of Primavera does NOT consider the resource calendars. Rather, it considers the activity calendar. 

For example: A resource is assigned to work on an activity. The resource calendar informs that the assigned resource will not be available on the coming Monday, but the activity calendar (separate one) informs of no holiday on Monday. 

This activity calendar will override the resource calendar. The duration of the activity will be determined by the activity calendar.   

Resource Dependent Activity

This, in a way, is the opposite of the Task Dependent activity. In this case, the resource calendar will be the driver of the activity. 

Here, the resources assigned to an activity will be scheduled on the resources’ calendars, not the activity’s calendar. 

Start Milestone Activity

Milestone, in formal project management terms, is a significant event in a project, program or portfolio. It’s not considered to be an activity. It's of zero duration. 

However, Primavera 6 software considers Start Milestone as an activity with zero duration. You can also call it a “Zero Duration Activity". As the duration is zero, there is no impact of resource assignment on this activity. However, you can have expenses associated with it!

Finish Milestone Activity

Like the Start Milestone, Primavera 6 also considers Finish Milestone as an activity with zero duration. As the duration is zero, there is no impact of resource assignment on this activity. Here too, you can have expenses associated.

The figure shows both Start and Finish milestones for the Information Management System project.  

As you can see in the “Start” and “Finish” column of the table in the left-side:

• The Start Milestone has the Start date set, not the Finish date.
• The Finish Milestone has the Finish date set, not the Start date.
• Both are of zero days duration. 

Level of Effort (LOE) Activity

This is an activity type that confuses many. But it’s actually simple. It’s like a hammock activity, but not exactly the same.  

The LOE activity’s duration is dependent on its predecessors and/or successors. In fact, it's linked to them, but its behavior is based on the predecessor and/or successor activities. Do note that while leveling resources, these activities are ignored.

The below figure shows a LOE activity associated with Management Work. 

WBS Summary Activity

This is another one which is considered to be complicated, but it’s not. To use this activity, you need to understand the basics of Work Breakdown Structure (WBS). 

As the name tells, the WBS Summary Activity summarizes at a WBS level. One example is shown below. 

As shown above, under the Requirements and Analysis phase (WBS level is WEB 2.5.2), we have added a WBS Summary Activity:

• Summarizes the activities of the Requirements and Analysis Phases WBS and its elements.
• Has the same Start and Finish dates.
• Has the same duration.

This can be reconfirmed with the following view, where I’ve added:

• WBS Name, and
• WBS 

As shown the WBS activity summarizes all elements at a WBS level, which is WEB 2.5.2.

Video Demonstration: P6 Activity Types  

The below video explains various activity types used in Primavera P6. The duration is around 5 minutes [5m:40s]. Put your earphones and go full HD in order to have a better experience. 

In Summary 

When you go for scheduling with Primavera P6, you’ll find various types of activities. They are complex, or even complicated. However, you need to have the right material and proper content to understand and visualize them practically.

When you understand the activity types, you can effectively apply them into your project management plan.

References

[1] Article: WBS Level – 0 (L0) Vs. Level – 1 (L1) with Oracle Primavera P6 and Microsoft Project, by Satya Narayan Dash

[2] Course: Practical PMP with Oracle Primavera P6, by Satya Narayan Dash

[3] Article: Work Breakdown Structure (WBS) in Traditional and Agile Life Cycles with MS Project,  by Satya Narayan Dash

[4] Article: Level of Effort Activity in Primavera P6, by Satya Narayan Dash

Management Yogi's Scaled Agile (CIPSA) Certification: 15 Free Questions and Answers (Part - 2)

This is in continuation of the earlier series of questions for Management Yogi's Certified In Practical Scaled Agile (CIPSA) certification exam. 

I'll definitely suggest that you take both the question parts together, when you attempt the questions. This way you will have continuation in your learning and get a better understanding on what kind of questions may come in your CIPSA exam. 

Also, as mentioned in the previous series, to answer these questions, you need to have: 

• Solid understanding of Scaled Agile Management practices scaling both team-level Scrum and team-level Kanban. 
• Excellent grasp of the CIPSA framework,  because the CIPSA certification course follows this framework. 
• Sound understanding on MS Project Scaled Agile features. 
• Good understanding of traditional (waterfall), team-level Scrum and team-level Kanban management.
• Critical thinking, logical reasoning, and ability to think out of the box. 

These questions are taken from the course: Certified In Practical Scaled Agile (CIPSA)  

Again, I hope you enjoy doing these questions and it helps in your preparation for the CIPSA exam.


[This series - Part - 1]

*********

Question – 9: A new Principal Scrum Master has joined your CIPSA team. She is a good performer and learning quickly on the job, but new to the CIPSA framework. A number of activities are conducted by her and you’re guiding her as a CIPSA certified professional. But which one of the following you’d advise her not to do?

A Improve the effectiveness of the Scaled Scrum such as higher quality, lesser number of bugs and lower cost.

B Take the customer feedback, assess them, and when needed, adjust the Product Backlog.

C Ensure cross-team collaboration and communication.

D Facilitate the removal of impediments, mitigation of risks and resolution of issues, with focus on cross-team dependencies.

Question – 10: As the Chief Product Owner (CPO) first presented the Product Backlog and Product Goal, the CIPSA Scrum Team has decided on the product backlog items to be taken-up for the upcoming Sprint. Then the individual Scrum teams took the backlog items and broke them down into individual tasks. Next the team proceeded with the execution of those tasks. Which important step did the CIPSA Scrum team miss?

A The team did not check if the Product Goal is achievable. 

B The team has not refined the cross-team backlog refinement.

C The team did not build the CIPSA Sprint Goal 

D The team missed to validate the Product Goal

Question – 11: For a networking project, a CIPSA Scrum team is going with the first meta-event. They have taken the high-ordered requirements and decided which of these requirements can be fulfilled in the upcoming iteration. The initial set of the dependencies are also noted. As the team closes this event, what are the likely outputs?

A Product backlog with a product goal

B An integrated increment that can be demonstrated 

C Individual Team Sprint Goals with Team Sprint Backlogs

D CIPSA Sprint goal with a CIPSA Sprint Backlog

 

Question – 12: For an ongoing Scaled Scrum project, the CIPSA team has completed a number of backlog items taken from the Product Backlog. As another Sprint approaches, one of the Team Product Owners disagrees with having another CIPSA Sprint Goal and says not to have more such goals. How many CIPSA Sprint Goals can be there?

A Three 

B Not more than five

C As many CIPSA Sprint Backlogs

D As many backlog items taken

Question – 13: Your Scaled Scrum project is in Sprint 5, you have prepared the Product Backlog, CIPSA Sprint 5 Backlog and Team Sprint 5 Backlog for all the Scrum teams. Now you want to visualize these goals in the cards of the Scrum Board. Current Cards are showing these fields.

Which field can be added into the cards to see these goals?

A Product Goal field

B Goal field

C Notes field

D Sprint field

Question – 14: Who is accountable for the items which will give the highest return on investment (ROI) when the Product Backlog is cross-team refined?

A CIPSA Team

B Principal Flow Master

C Chief Product Owner 

D Individual Team Product Owner

Question – 15: For a Scaled Scrum project, the Task Burndown Chart for the entire CIPSA team is shown below. Based on it, what can be correctly said about the progress?

A The CIPSA team is well ahead of schedule and likely to complete all the work items

B Few individual Scrum teams within the CIPSA team are not performing

C The CIPSA team is behind schedule and may miss some of the tasks at the end of the Sprint

D Sufficient planning has not taken place for the CIPSA team

[This series - Part - 1]

*********

The question set is available in the embedded document below. The answers are also part of this document.

For all answers, subscribe to this site and send a mail (from your GMail id) to managementyogi@gmail.com.

You May Also Like:

1. Frequently Asked Questions (FAQs) - Certified In Practial Scaled Agile, by Satya Narayan Dash

2. Certified In Practical Scaled Agile certification course (CIPSA), by Satya Narayan Dash

3. Step-by-Step Guide: Install, Set-up and Run MS Project 2024/2021/2019 with Agile Features (Online Desktop Client)