Tuesday, March 12, 2024

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] Online Course: Mastering MS Project Agile, by Satya Narayan Dash 

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



Monday, March 04, 2024

WBS Level – 0 (L0) Vs. Level – 1 (L1) with Oracle Primavera P6 and Microsoft Project

 

Many times, while interacting with the project management or agile practitioners, questions come on the levels of the work breakdown structure (WBS). In particular, the biggest confusion is about the differences between Level 0 (L0) and Level 1 (L1). 

Most project management literature and tools are focused on L1 of the WBS and rarely mention L0! This results in questions such as:

  • Is L0 possible in a WBS?
  • What does it represent?
  • How is it managed with a software tool?

In this article, I’m going to explore the answers to the above questions with hands-on practical software tools. First, to understand, let’s briefly discuss various levels of WBS.

Various Levels in WBS

Following are the levels of WBS:

WBS Level – 1: This is the highest level in a WBS and it represents the entire scope of work to deliver the product or service.

Considering an example of TESTPROJECT (name of the project), it can be assigned a numerical number 1 or a WBS code TESTPROJ. We will see them with examples shortly.

WBS Level – 2: This is the first level of decomposition. These are the major deliverables or areas of work. Remember, a WBS is a deliverable-oriented hierarchical decomposition of work. It means the WBS is broken-down/decomposed the way you want to deliver your work. 

Considering our previous example, the numbering at L2 will be:

  • 1.1, 1.2, 1.3, 1.4, … 1.n
  • Using TESTPROJ code, it’ll be TESTPROJ.1, TESTPROJ.2, TESTPROJ.3, TESTPROJ.4, … TESTPROJ.n

WBS Level – 3: It’s the next level of decomposition or decomposition of L2. Here one can have the major deliverables/areas of work broken down further for better estimation and understanding.  

The numbering schemes here can be:

  • 1.1.1, 1.2.1, 1.3.1, 1.4.1, … 1.n.1
    • At the level of 1.1.1, you can have 1.1.2, 1.1.3, 1.1.4 …
  • Using TESTPROJ code, it’ll be TESTPROJ.1.1, TESTPROJ.2.1, TESTPROJ.3.1, TESTPROJ.4.1, … TESTPROJ.n.1
    • At the level of TESTPROJ.1.1, you can have TESTPROJ.1.2, TESTPROJ.1.3, TESTPROJ.1.4 …

What is Level – 0 (L0)?

This is where the confusion comes-up! Why does one need Lo?

To simplify, here are certain key points with respect to L0:

  • If present, it’s the highest level of the WBS tree or tabular structure.
  • Below L0, in the WBS, you will have L1.
  • L0 is NOT used in the numbering schemes, rather L1 is taken-up for it.
  • L0 is useful, when you are managing multiple projects together in a single file. For example, one can have a large project with multiple WBS (each starting with L1). 
  • Looking at the previous point, all smaller projects, under a large project, can have their own numbering schemes. 

Now, let’s see the practical usages of it.  

L0 and L1 - Oracle Primavera P6

Primavera allows up-to 20 WBS levels by default. You can check the levels under the Admin menu > Admin Preferences > Data Limits tab. I’ve changed it to four for this article.

Next, I added four levels in the WBS tab of Primavera P6’s main screen. 

As shown above:

  • TESTPROJ = Level – 1
  • TESTPROJ.1 = Level – 2
  • TESTPROJ.1.1 = Level – 3
  • TESTPROJ.1.1.1 = Level – 4

So, the highest level is Level 1 in Primavera P6. 

Next, I’ll modify this WBS to make it more formal and have a couple of work packages. 

As you can see, now we have two work packages: Work Package 1 and Work Package 2 at L2. The WBS codes are WP1 and WP2, respectively. The Project ID is another column as TESTPROJ, which is L1. 

Did you notice how the WBS code is noted? It’s ProjectCode.WBSCode, e.g., TESTPROJ.WP1.

Next, for each work package, we have four activities and they are all linked with finish-to-start (FS) dependencies. This is shown in the Activities tab. I’ve added the WBS, WBS Name columns under the Activities tab to have better clarity.

As one can check, there is a Work Package 1 (WBS Name) that has a WBS (Code) as TESTPROJ.WP1. It has four tasks: Task 1-1, Task 1-2, Task 1-3, and Task 1-4. All the tasks in the respective packages are linked.

Considering the WBS levels, we can have following interpretations:

  • Highest level is TESTPROJ (L1).
  • Next level is TESTPROJ.WP1 (L2) and TESTPROJ.WP2 (at Level 2).
  • These are also reflected in the graphical side of the Gantt Chart.

Hence, in Primavera P6, there is no Level 0 (L0), but only Level 1 (L1). This L1 can be further decomposed to any level you want.

L0 and L1 - Microsoft Project 

To demonstrate Level 0 (L0), I’m going to use the MS Project software. The below commands/usage will be valid for all versions of MS Project from MS Project 2003. 

Just like the previous situation, here too, we have a Test Project (Project Name) with two work packages – Work Package 1 and Work Package 2. Each work package has four activities. The plan is shown below. 

Unlike Primavera P6, there is no separate WBS tab or command available in MS Project. To see the WBS code, you have to add the “WBS” field available in the software. This can be added by right clicking and using the command “Insert Column”. 

When added, we will get the following view.

As shown above, in the Test Project we have two work packages (WP 1 and WP 2).

  • Test Project = L1
  • Work Package 1 and Work Package 2 = L2
  • Various tasks under the work packages = L3

So, where is L0?

For that, you have to enable the Project Summary Task command under Format tab > Show/Hide group. 

After you enable it, Level 0 (L0) will appear in the MS Project plan as shown below.

As shown:

  • A new line entry is auto-added and it’s named Project 1This is Level 0 or Lo.
  • This is one level up the L1 and also shown in the graphical side of the Gantt Chart.
  • The lower levels such as L2 (work packages) and L3 (tasks) are also shown.

Conclusion

In conclusion, you can say Primavera P6 does not have L0, but MS Project does! Earlier in the article, I’ve noted certain key points about L0 for a WBS.

Another usage of L0 is when in the same project, you have different kinds of work and you want to keep them all at L1. Say, a project has different work and you want to have different WBS codes being applied to those work. With L0 availability in MS Project, you can perform those operations.

However, if you are using Primavera P6, there is no L0 and it’s not needed. This is because in Primavera, the WBS code is built separately in another tab and then activities are added to the WBS levels. 

I hope this article gives clarity on how and when the L0 and L1 are used in a work breakdown structure with real-world and widely used software tools.


References:

[1] Online Course: MS Project – Live Lessons, by Satya Narayan Dash.

[2] Article - Work Breakdown Structure in Traditional and Agile Life Cycles, by Satya Narayan Dash


Sunday, February 25, 2024

Leading Indicators and Lagging Indicators in Project Management


For the first time, in the PMBOK® Guide 7th edition, both leading and lagging indicators are introduced as Key Performance Indicators (KPI) for a project. Such indicators are applicable in all aspects of management – project, program, portfolio or risk management. It’s also applicable in Agile management.

Let’s understand them in simplest possible terms. The content of this article has been taken from RMP Live Lessons – Guaranteed Pass.


Indicators

I’ll define an indicator as follows:

“An indicator is something (a result, an event, a statistic) that indicates or signals.”

For example, if you are finding a number of bugs in your team’s deliverables, it indicates a quality problem. Based on it, you can take some actions such as having a more robust definition of done (DoD)

Taking another example related to our personal lives, if you see a cloudy sky, it indicates that rain may happen next. Based on it, you may choose to take some actions such as taking an umbrella or searching for your raincoat.

The first result (high number of bugs) is a lagging indicator. This is because you came to know about it after the bugs occurred. But the second one is a leading indicator for rain. Because before the event occurred (rain), you came to the possibility of the event happening. 

Now that I’ve introduced two more terms – leading and lagging indicators – let’s understand them in detail. 

Leading Indicators

I’ll slightly change the definition provided by the Project Management Institute (PMI®) and will define it as:

“A leading indicator is a measurable data that helps to anticipate (predict) changes or trends in a project.”

Simply put, a leading indicator is about the future or it indicates the future. 

Some of the examples in management can be the followings:

  • Lack of a risk management processes
  • Stakeholders who are not available or engaged
  • Poorly defined project success criteria
  • Size of the project (quantifiable)
  • Complexity of the project
  • Number of items in progress after taken Backlog (quantifiable)

Considering the last example of too many in-progress items indicate a bottleneck in flow of work, or too complex work being taken-up. 

Lagging Indicators

Here too, PMI provides a good definition, but I'll modify a little:

“A lagging indicator is a measurable data that measures deliverables or events in a project.”

Simply put, a lagging indicator is about the past or it gives information about the past. 

Examples of lagging indicators can be:

  • Number of deliverables completed (quantifiable)
  • Schedule variance (quantifiable)
  • Cost variance (quantifiable)
  • Amount of resources consumed (quantifiable)

Taking the first example, one can say that if you are completing a good number of deliverables, then the project is progressing well. 

Next, I’m going to relate leading and lagging indicators with preventive and corrective actions, which you have to know as an aspiring PMP, PgMP, or RMP. 

Leading Indicators and Preventive Actions

As defined by PMI:

A preventive action is an intentional activity that ensures the future performance of the project work is aligned with the project management plan. 

For projects in an Agile environment, it'll be your product backlog with the product goal. In other words, the actions should be aligned with the product goal (or release goal or Sprint goal). 

Leading indicators can lead to preventive actions. With it, before the event or condition happens, you can take actions. For example, considering our first example, before the rain event happens, you can take actions such as taking an umbrella.

Lagging Indicators and Corrective Actions

As per PMI: 

A corrective action is an intentional activity that realigns the performance of the project work with the project management plan. 

For projects executed with Agile frameworks, you will be taking actions that realigns with the product goal, release goal or Sprint goal.

Lagging indicators can result in corrective actions. For example, schedule variance is a lagging indicator. If very high variance, you can take actions with techniques such as fast tracking or crashing to improve. 

Comparison  Leading and Lagging Indicators

The comparision with both the differences and commanalities between leading and lagging indicators are shown in the table below.


Both these indicators are part of the Measurement Performance Domain (PD) of the PMBOK Guide, 7th edition. Because these indicators are primarily about measurement. The PMBOK guide prudently notes and I quote verbatim:

“In and of themselves, KPIs are simply measures that have no real use unless and until they are used. Discussing leading and lagging indicators and identifying areas for improvement, as appropriate, can have a positive impact on performance.” 

Indeed, measurements should be used. In my view, as a management professional and leader, you should measure (and use) both leading and lagging indicators. In fact, I'd say it's a best practice to use both in your projects.


References

[1] Project Management Body of Knowledge (PMBOK) Guide, 7th edition, by Project Management Institute

[2] RMP Live Lessons - Guaranteed Pass or Your Money Back, by Satya Narayan Dash