Understanding PMI Exam Score Reports

While preparing for Project Management Institute (PMI) related exams, it’s highly important to know how the scoring happens and what basis the scoring happens. It’s equally crucial to know when and why you will be considered to have passed or failed the exam. 

PMI provides a number of certification exams. Some of them are:

• Project Management Professional (PMP) Exam,
• Risk Management Professional (RMP) Exam,
• Agile Certified Practitioner (ACP) Exam,
• Portfolio Management Professional (PfMP) Exam,
• Certified Associate in Project Management (CAPM) Exam.

In this article, we will know the importance of ECO, how the exam rates your performance and dissect the PMI Exam Reports. Going forward, I’ll be using scores from varieties of PMI exams, including PMPs because I’ve seen hundreds of them personally. This is also important to know for you as an exam taker. 

In all my PMI exam related books and/or courses, including Agile, I’ve consistently emphasized on the Exam Content Outline (ECO), on which every PMI exam is based upon. For example, the PMP Exam as popularly believed is actually not based on the Project Management Body of Knowledge (PMBOK) Guide, but on the ECO! The RMP Exam is also not based on the Standard for Risk Management in Portfolios, Programs and Projects, but again on the ECO for the RMP Exam. Similarly, it’s applicable to all other exams such as PfMP or others.

Importance of the ECO

The ECO is important because you will be evaluated on the domains of the ECO. For example, in the PMP Exam, there are 3 domains:

• Domain I - People
• Domain II – Process
• Domain III – Business Environment

You will be evaluated on these domains, the associated tasks and enablers. 

For the RMP exam, there are 5 domains:

• Domain I – Risk Strategy and Planning
• Domain II – Risk Identification
• Domain III – Risk Analysis 
• Domain IV – Risk Response
• Domain V – Monitor and Close and Risks

Again, each of the above domains will have tasks and enablers. You will be evaluated on each domain. 

Now you might be thinking, how do you know you have passed or will pass the exam?

For that, you have to understand the performance rating categories. 

Performance Rating Categories

There are four performance rating categories:

• Above Target (AT): Your performance exceeds the minimum requirements for this exam.
• Target (T): Your performance meets the minimum requirements for this exam.
• Below Target (BT): Your performance is slightly below target and fails to meet the minimum requirements for this exam. Additional preparation is recommended before re-examination.
• Needs Improvement (NI): Your performance is far below target and fails to meet the minimum requirements for this exam. Additional preparation is strongly recommended before re-examination. 

The targets are expressed in ranges. It helps you to see how you scored in the exam with respect to the performance domains. It’s overall performance across all the exam domains. 

A sample exam report has been shown below, where the candidate has passed the exam.  

As you’d noticed in the above figure, it’s clearly written on top: PASS. It means the candidate has passed the exam. 

But then there are multiple zones (ranges) mentioned for the performance categories with multiple color coding. What are they?

Let’s take a real exam report to understand.

Some Real PMI Exam Reports

The below snippet is from a real PMP exam. Here the candidate PMP has successfully cleared the exam and is a certified PMP. You can read the PMP Success Story.

 

As shown above:

• The exam report is divided into two zones: Failing Zone and Passing Zone.
• The final score pointer (the black vertical line with the marker 'YOU' on top) is showing the final result. 
• If the pointer is falling in the failing zone, then you have failed. If the pointer is falling in the passing zone, you have passed the exam. 
• Sometimes the pointer is exactly in the middle! But again, it will still be in the passing or failing zone. 

For the above one, the pointer is in the AT zone (Above Target) and obviously the candidate has scored AT in all PMP exam domains. 

I just informed you that the pointer can be exactly in the middle. Did you read that line? If you have, again note that scoring will still happen! 

The below score report is from a real PMI exam. The candidate was very unlucky here. Just one or two questions correctly answered and the candidate would have been a certified RMP. Sigh! I felt very sad to see this report. 

In the above figure, you can see the pointer is exactly in the middle, but it’s touching the far-end border of the Below Target (BT) zone! If it would have been the near-end border of Target zone, then the candidate would have passed the exam. 

There are others like the two shown below. Again, these are from real PMI exams. As seen, candidates mostly fail because they follow the wrong providers or coaches. Your provider and coach matter. Both will be instrumental for your successes in the exams.

Another one is shown below from a PMI exam.

Again, notice the statement in the above figure with a pointer in BT zone: The performance is slightly below target. With additional preparation, you have a high chance to clear the exam. 

Now, while for the first one, the pointer is in the Needs Improvement (NI), for the second one the pointer is in the Below Target (BT) zone. 

Also, did you notice the color coding?

If not, re-look at them again. This is typical Red-Orange(Yellow)-Green color coding. 

• If it’s in the NI zone, the color coding will be red.
• If it’s in the BT zone, then the color coding will be orange/yellowish.
• If it’s in the T zone, then the color coding is blue. 
• If it’s in the AT zone, then the color coding will become deep blue. 

At this stage, another question comes-up:

How does this overall performance rating category relate to individual domain related rating categories? 

Let’s take an example to understand. 

This the expected segregation of questions as per the ECO.

Domain Based Segregation

In this case, I’ll take the Risk Management Professional (RMP) Exam. In this case we have five domains and any of the above four performance categories can come for these five domains. 

Let’s say a candidate has scored the following: 

• Risk Strategy and Planning: T 
• Risk Identification: AT
• Risk Analysis: BT
• Risk Response: AT
• Monitor and Close Risks: AT

In this case as the candidate has scored AT and T in most of the domains, except one. Obviously the candidate has passed the exam. And of course, the score pointer will be under the passing range. 

The individual domain related scoring for the above case is shown below. 

As shown above, each domain has a performance rating category and they are color coded. This comes with a pie chart, whereas the overall performance rating category will be in the bar chart.

Various Possibilities 

Now, one of the most important parts is to know if you have passed or failed the exam. In other words, what are the possible combinations in which one can definitely say to pass or fail the PMI exams. 

With absolute certainty, one can say the following:

• If you are scoring Above Target (AT) and/or Target (T) in all exam domains, then you’re definitely going to the exam. Mark the word ‘definitely’. 
• If you are scoring Below Target (BT) and/or Needs Improvement (NI) in all exam domains, then you will definitely fail the exam! Again, mark the word ‘definitely’. 
• If you can score AT in the vast majority of the domains (4 out of 5) and not fall under NI for any domain, then you will pass the exam.

Conclusion

Other than the above ones, nothing can be conclusively said, except the following.

• Never ever fall into the Needs Improvement zone. It will pull your overall score down and highly likely that you will fail the exam. 
• Considering 5 domains, if you have 2 or more NI ratings, then you’d definitely fail the exam!

In other words, don’t leave any domain unprepared (not underprepared). Go through each domain, learn as much as you can, practice as many questions as you can before you appear for the exam. 

I hope you understood the importance of ECO, related domains and how you should target to prepare for PMI related exams.

I wish you all the very best for your PMP, RMP, ACP, PfMP and/or other PMI related exams.

References:

• PMP Live Lessons – Guaranteed Pass or Your Money Back
• RMP Live Lessons – Guaranteed Pass or Your Money Back
• ACP Live Lessons – Guaranteed Pass or Your Money Back

Ten Myths and Facts – Contingency Reserve and Management Reserve

 

Management Reserve and Contingency Reserve are two widely used reserves in Project Management, Program Management. It can also be used in Portfolio Management and Agile Management, though the way there are used will be somewhat different. However, there are many misconceptions about these two reserves. In this article we will see what those myths are and check upon the facts. 

These explained in my courses such as:

• PMP Live Lessons, Guaranteed Pass or Your Full Money Back
• ACP Live Lessons, Guaranteed Pass or Your Full Money Back
• RMP Live Lessons, Guaranteed Pass or Your Full Money Back

The needed content is also available as part of the PMP 35 Contact Hours, RMP 30 Contact Hours, ACP 21 Contact Hours and CAPM 23 Contact Hours courses. 

Note: First go through the myths on your own and try to answer yourself. That way you will get a better value from this article.

Hope you are tried to do the exercise on your own first! I'll also suggest that you go through this article to learn more:

Article - Contingency Reserve and Management Reserve

Now, let's see the myths and facts. 

Myth – 1: Addition of contingency reserve to activity cost estimates (or activity duration estimates) will create a rubber baseline. 

Fact: Contingency reserve can be at the activity level or work package level etc. If it’s at the activity level, then it need not be at the work package level. The reserves from lower level estimates will get rolled up to the work package level. Hence, there is no chance of having a rubber baseline. 

As you can see in the above block representation, the contingency reserve can be at the activity level, or work package level. Otherwise, you can have an overall contingency reserve at the project level.

Myth – 2: Contingency reserve is not applicable for the project schedule, it’s only for the budget.

Fact: It’s applicable for both project schedule and project budget. You can have contingency reserve calculation while determining the duration estimates of tasks or cost estimates of tasks. 

Refer to the previous diagram to see overall contingency reserve.

Myth – 3: Any reserve can be tracked with a reserve burndown chart.

Fact: Usually, contingency reserve is tracked at the project level, but management reserve is not. The reason is simple. Project Managers know and manage the contingency reserve as it’s part of the performance measurement baseline. 

So, the reserve burndown chart that one creates and manages at a project level is with respect to the contingency reserve, not for management reserve.

Myth – 4: If the reserve is unused, then it can be part of project profit! 

Fact: This is another big myth propounded. But you can’t take the unused reserve as part of the profit. It’s meaningless because you have added the reserve for unforeseen circumstances. 

• Threats – if the reserve is unused then, it has to be removed or given back. 
• Opportunities – if the reserve increases because you exploited the opportunity, then yes, for this you can consider it to be a profit.

Re-read the previous line! In risk management, both threats and opportunities are considered, but the way they are treated will be different. 

Myth – 5: Reserves have little to no role to play in S-curve interpretation. 

Fact: In fact, it’s the other way around. You should be worried when the reserve starts getting depleted while doing your S-curve analysis. The Budget at Completion (BAC) in earned value calculation should include the contingency reserve (CR).

Sometimes the estimate at completion (EAC) can go beyond the available contingency reserve and may eat-up the management reserve (MR).

                                                                

As shown in the above S-curve, the trend for Actual Cost (AC) curve is upward and it may consume not only the contingency reserve, but also the management reserve for the project.

Myth – 6: Slack or float can be a replacement for contingency reserve.

Fact: Slack and reserve are two completely different concepts. Many confuse the two. 

Total slack is about how much time you can delay a task without delaying the project end date. Free slack, simply put, is how much you can delay a task without delaying any successor task. 

Reserve or allowance on the other hand protects you against the delay in the current activity, not next activity’s start date! 

Myth – 7: Contingency reserve and contingency response planning are one and the same thing. 

Fact: Contingency as we know is the reserve for known risks, but unknown amount of rework. It’s for risks which are accepted or known risks with active risk response strategies. 

Contingency planning, on the other hand, consists of two plans: Contingency Plan and Fallback Plan. Simply put, these two plans are Plan A and Plan B, respectively that we use in our day-to-day risk management. 

Myth – 8: Agile projects don’t have all these reserves available.

Fact: In Agile projects, too, you may require contingency and management reserves. Consider an Agile project with mandatory regulatory requirements and one of the needs to meet the budgetary regulations with earned value calculations. In such a case, you need to have the reserves. 

Myth – 9: Management Reserve is a budget category, and not applicable for Schedules.

Fact: This is another myth, which is widely circulated. While management reserve is usually a budget category, you can also have it for schedule. In fact, the definition of Management Reserve as per the PMI-PMBOK guide is this:

An amount of the project budget or project schedule held outside of the performance measurement baseline for management control purposes that is reserved for unforeseen work that is within the project scope.

Can you see that the management reserve can also be part of project schedule (not just budget)?

Myth – 10: Contingency Reserve and Contingency are one and the same thing.

Fact: Contingency is an event or occurrence that could affect something, e.g., a task, a work package or the execution of the project. Contingency reserve, on the other hand, is the time or money allocated for known-unknown risks. However, contingencies can be accounted for with reserves.

There are many other myths, which circulate on these two reserves. What are the other myths you think are not correct for contingency reserve and management reserve?

If you have any questions, suggestions or feedback, do share your comments in the comment section of this article.

References:

1. PMP Live Lessons, Guaranteed Pass or Your Full Money Back, by Satya Narayan Dash

2. ACP Live Lessons, Guaranteed Pass or Your Full Money Back, by Satya Narayan Dash

3. RMP Live Lessons, Guaranteed Pass or Your Full Money Back, by Satya Narayan Dash

Agile Asanas: Closing A Project Vs. Closing A Sprint

 

Any genuine management practitioner will tell you that a project has to be closed, irrespective the methodology or framework being used. If it’s a traditional project and/or a project having multiple phases, then not only the project has to be closed, but each project phase has also to be closed. 

[ This post is part of the Agile Asanas series. 

To read all posts in Agile Asanas series, use this link. ]

Closing a project entails a number of activities and it’s advantageous for the project manager to do so. 

Now, because a Sprint is considered to be a mini-project, it also has to be closed, irrespective of the decomposition patten being followed such as:

• Project, Release, Feature, Sprint, Use Story
• Project, Feature, Release, Sprint, Use Story
• Project, Epics, Feature, Sprint, Use Story
• Project, Sprint, User Story

Going forward, I’ll be using the decomposition pattern of Project > Release > Sprint > User Story. 

Recently, I wrote a couple of articles regarding project closure and Sprint closure. I’d strongly recommend that you read both of them along with this piece. 

• Closing A Project – Hands-on and Step by Step
• Closing A Sprint – Hands-on and Step by Step

In this article, we are going to explore the differences between project and Sprint closures. For management practitioners, who want to be proficient across the spectrum of project life cycles and development approaches, it’s important that you know the differences.

*********

First the definitions. 

A project is defined by the Project Management Institute (PMI) as follows:

A project is a temporary endeavor to create a unique product, service or result.

Do note that the definition says that a project creates something unique. It can be a product, service result. This definition is not about a deliverable or increment at the end of the project – rather, it’s a finish product. 

I define Sprint as follows:

A Sprint is a time-boxed iteration event within the Scrum framework.

The Sprint event contains four other events: Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Each Sprint can be considered to be a short project as noted in the latest Scrum Guide, 2020.

An increment of value is delivered at the end of the Sprint or prior to the Sprint. An increment is a step towards the Product Goal. You can learn more on increments and Product Goal in the below article:

Top Changes to Know for Scrum Guide 2020

With these foundational understanding, let’s see the differences one by one. 

Difference – 1: You close a Project once, but close Sprints many times.

A project is closed only once. If a project has multiple phases, then each phase is closed separately and these steps can happen multiple times. However, the project closure is the final one and happens once.

On the other hand, the Sprints are closed multiple times. After all, a project can have many releases, which in turn will have many Sprints. 

All these Sprints can be closed within the life cycle of a project. 

Difference – 2: Final increment is at the end of the Project, intermediate and/or multiple increments can happen anytime within a Sprint.

As we saw earlier, a project creates/builds a product (or service or result). Basically, it’s a deliverable or collection of deliverables. A deliverable is a uniquely verifiable product (or service or result) that is produced to close a project or phase. 

On the other hand, an increment (similar to deliverable) is produced at the end of the Sprint or prior, but within a Sprint. The increment given at the end of the Sprint is a sum of previous increments. An increment is not a finished product. 

Difference – 3: Resources are released when a project is closed. Resources are likely to remain when a Sprint is closed.

When a project is closed, all the resources are released. You, as a Project Manager, has to do it because you are accountable for the time spent and cost involved for the resources.

But when you close a Sprint as a Scrum Master, you don’t release the resources. Because those will be needed in the upcoming Sprints. 

Do note that in Agile, the team is cross-functional, self-organizing and self-managing, but procurement, hiring and release of resources (both human and non-human) are facilitated by the Product Owner and/or the Scrum Master. 

You can learn more roles being played in Agile and Traditional environment in the below article:

Agile Asanas: Mapping Traditional Project Roles to Agile Frameworks

Difference – 4: Final Report is given at the end of the Project, whereas usually Burndown Chart is enough for a Sprint end.

The final report given at the end of the project is quite exhaustive. This is the summary of project performance. It informs if the scope, schedule, cost and quality objectives are met, the achievement of business needs/objectives of the project, among others.

But, when a Sprint is closed, there is no such exhaustive reporting or documentation. Usually, Burndown Chart is enough to inform on the work completed. 

If you want, you can show certain additional information in your Sprint Report such as features completed vs features planned, velocity (story completed vs planned), issues faced, risks register and addressed. But remember, in Agile, one the values is this:

Working software/product over comprehensive documentation.

Difference – 5: Usually Projects will have Lessons Learned Meetings, whereas Sprints will have Retrospectives!

You may have noticed that Lessons Learned Meeting and Retrospectives are used interchangeably. But there are subtle and important differences. 

Lessons Learned Meeting is a periodic meeting, where the team meets to determine what they could do better in the future with a focus on improving team performance. Lessons learning happens throughout the life cycle of the project. However, the final Lessons Learning Meeting happens at the of the project. The ‘lessons learned’ is then archived into the organizational repository. 

Retrospectives, on the other hand, happen for the iterations or Sprints in our case. It has a recurring pattern and specificity. Here, the team meets how they can improve the process and product in the upcoming Sprints. 

Retrospective is a form of lessons learned meeting, but they are not the same.

Difference – 6: Project documents are closed and archived. A Product Backlog is not closed or archived. 

Project documents such as Requirements Documentation, Scope Statement (part of the Project Management Plan) are closed/completed/reviewed and archived at the end of a Project.

A Product Backlog used in a Scrum Project is not closed and archived when a Sprint gets closed. It’s a live document and continuously gets updated. 

In fact, at the end of the Sprint, the backlog is likely to get updated with the improvement items coming from the Sprint Retrospective event. Again, notice that it’s Sprint Retrospective, not Sprint Lessons Learned Meeting! I’ve already differentiated the two in the earlier point. 

Difference – 7: A project is a temporary endeavor with a longer time-span, whereas Sprint is a short time-boxed event.

This comes from the definition itself, which we saw earlier. A project is not timeboxed, i.e., when the time is over the project is over! The time-span of a project can be elongated or shortened. 

On the other hand, a Sprint is always a timeboxed event. If the Sprint duration/length is of two weeks, then the Sprint has to be closed at the end of two weeks. 

It doesn’t matter if the work taken to be completed within the Sprint is complete or not. It has to be closed! 

Difference – 8: Formal activities for contract closure happens at the end of the project, whereas contracts can be closed within a Sprint.

This difference is slightly tricky. 

At the end of the project, one considers both contract closure (all final payments made, no outstanding claims etc.) and administrative closure of the contract (confirming formal acceptance of deliverables, finalizing open claims etc.)

A contract can be closed during a Sprint when the deliverables have been given by the contractor and accepted. However, the administrative closure of the contracts can be time consuming and a Sprint is timeboxed. Hence, it’s not preferably done in a normal Sprint.

Difference – 9: Project Audits happen at the end of a project, but doesn’t usually happen within a Sprint.

The project audit is mainly to check the project success or failure. The success criteria are documented in the Project Charter document.

However, an audit usually doesn’t happen at the end of a Sprint. Audit is time consuming on its own and hence, a short time-boxed duration of Sprint can’t really accommodate the need.  

Also, as the customer (or proxy of the customer, which is the PO) is directly involved daily in Sprint, one need not go for an audit to check the success and failure for a project. 

--

Similarities

There are also similarities between the closure of a project and a Sprint. Below, I've noted some examples:

• Acceptance of deliverables/increments happens at the end. 
  For a Sprint, the acceptance (or rejection) happens in the Sprint Review event.
• The increment is handed over to the operations (in Project).
• In Agile, the increment is directly deployable and hence, usable or can be with the ops team (DevOps).
• Both Project and Sprint closures focus on value delivery.
  Increment must be of value to the end customer/user when delivered, so also a Project’s deliverables.
• A project can be prematurely closed, so also a Sprint.
• A project can be abnormally terminated, so also a Sprint. 

I believe with this you now have a fair understanding of the various differences between project and Sprint closures. If you have more things to add or have other comments and suggestions, do leave them in the comments section below.

References:

[1] ACP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

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

 

The Rhythmic Dance of Agile with Cadence

 

Odissi (pronounced o-dee-shee) is one of the classical dances of India from the coastal state of Odisha. Based on archeological evidence, it’s possibly the oldest living classical Indian dance. The Massachusetts Institute of Technology (MIT), US, notes in its web-archives that Odissi is two to three thousand years old. In recent decades, it’s been popularized by well-known artists—one being singer, Michael Jackson. In his famous 1991 song, Black or White, Jackson danced a fusion of Odissi and pop-rock, with his companion dancer, on the highways of the United States.

A unique dance position in Odissi is “tri-bhangi” (‘tri’ meaning three and “bhangi” meaning stance or position). Together, loosely translated, it means “thrice deflected stance,” and is quite difficult to master. In this position, there is a three- or tri-fold shape in the body forming an S-curve. To get into this stance, the upper part of the body such as head and hands are rhythmically moving in one direction, while the middle and lower parts of the body move in other directions with different rhythms. The joy of the dance for the viewer and performer alike comes through, in that parts of the dancer’s body are moving in rhythm, as well as the entire body moving, at large.

Now, you might be thinking what exactly a dance has to do with cadence in Agile?

Let’s start first with the definition of cadence.

Cadence – Definition and Basics *** UPDATED ***

One can define cadence in Agile as follows:
Cadence is a regular, predictable pattern of development work in Agile. It’s timeboxed and comes with consistent duration to help scheduling.  

Simply put, cadence is a rhythm of execution. The concept of cadence in Agile is suitably explained with a dance. With dance, art meets science, and in the same way, management meets life.

Like dance, cadence creates a predictable pattern of work or rhythm of execution.

Also, like dance, which can come with different rhythms for the different parts of the dancer’s body, cadence can be different for the different practices of Agile development. For example, you can have one cadence for Agile planning events, a separate cadence for Agile demonstrations or reviews, and a completely different cadence for Agile retrospectives. You can also have a single cadence for all events, for example, every two weeks, you may have planning, demonstrations, and retrospectives. We will explore a number of such situations shortly.

Taking another example from our own human bodies, many organs function in various cadences. For example, our heart beats on a cadence, our breathing or respiratory organ works on another, and so on.  In fact, if these vital organs of the body don’t operate on their respective cadences, life won’t exist!
That said, let’s explore how cadence can be applied in various Agile frameworks.

Working with Single Cadence
We have learned before, there can be two Lean-Agile frameworks at a high-level: iteration-based and flow-based. Irrespective of the type, cadence can be applied to development effort.

In iteration-based Agile, such as Extreme Programming (XP) or Scrum, an iteration length is prescribed. For example, in Scrum, where an iteration is called Sprint, the iteration length is usually less than a month (four weeks) as per my article on the latest Scrum Guide, 2020, and it’s always timeboxed.

When you keep the length of the iteration fixed over a period (and it is a good practice to do so), you develop a cadence. As we saw in our initial definition, it’s a predictable, regular pattern or rhythm of execution. When the iterations are repeated consistently over a period, a cadence is formed. In other words, in an iteration-based Agile, cadence is created with iterations, as depicted in the below figure.

Considering Scrum framework, the cadence is timeboxed, usually from two to four weeks and is created by a Sprint. Within the Sprint, you have a cadence, and it is a single one. When we modify it for Scrum, the figure will change to what is shown below.

Working with Multiple Cadences
Whereas in iteration-based Agile, the cadence is formed by iterations; in flow-based approaches such as Kanban, timeboxing is not prescribed. However, you can apply cadence here, too. You can choose when you do planning, when to release, and when to do a retrospective. You can decide on a set basis, such as a release every Friday, or you may choose an on-demand basis. It can also be based on when there is something valuable to release.

Below is an example of a team working with three cadences.

 

As shown above, we have:

• Every week the team releases whatever is ready for release,
• Every second week they have planning, and
• Every third week, they have a retrospective.

Working with Event-Based Cadence

A project manager could develop cadence based on events, as well. This approach is employed in flow-based Agile or, if the stakeholders decide to do so, in an iteration-based Agile. Below is a case depicting that. A planning meeting is started when the team runs out of items to complete. A release is triggered whenever the team has a set of features ready. A retrospective is done every two to four weeks.
 
Looking at the above figure, one could say that these are the event-based cadences:

• Planning Cadence: A planning meeting is started when the team runs out of items to complete.
• Retrospective Cadence: A retrospective is done every two to four weeks.
• Release Cadence: A release is triggered whenever the team has a minimally marketable feature (MMF) and/or subsequently, a set of releases.

Cadence and Project Life Cycle *** NEW ***
The cadence is quite important because along with development approach, it determines the project life cycle! In this case, I’m considering the delivery cadence. This is shown in the below figure. 

The delivery cadence informs how frequently the project deliverables are given. The deliverables can be given one-time (single delivery), multiple times (multiple deliveries), or periodically (periodic deliveries), among others.

Also remember that, development approaches can be many such as predictive (waterfall), adaptive (Agile) or incremental. A project life cycle can also be many types based on the development approaches. A project life cycle can be predictive, adaptive, hybrid (combination of predictive and adaptive) etc. You can learn more on development life cycle and project life cycle in this article.

Consider having a single delivery cadence, where the delivery will happen only at the end of the project. In such a case, one would go with a predictive life cycle. Similarly, considering multiple deliveries during development of software component for a car project can result in a hybrid life cycle.

Cadence and Intensity of Work
We know that an alert and healthy staff will always be more productive than if folks are tired or burnt out. For that, a sustainable pace is needed. However, in sequential/waterfall development model, this is not always the case.

Many times, it has been found that teams really can’t or don’t work with full productivity at the beginning of a project, especially, and it’s likely that they will start spending long hours and sleepless nights towards the end. In other words, the intensity of work goes-up towards the end of the project. Note the depiction of this in the below figure.
 

This late work towards the end of a project is known as death march, and it refers to the burnout and exhaustion of the team members. Obviously, this type of late work can lead to high attrition and the loss of talented resources. The Agile framework intentionally tries to put a stop to this risk. Hence, one of the principles of Agile Manifesto reads as:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

With short iterations, intense work doesn’t peak towards the middle or end of the project, but remains steady throughout the project’s life cycle. This is because a project consisting of multiple iterations, will have similar intensity densities.

Cadence – Advantages

There are many advantages of cadence, some of which are:

• It is easier for project managers to manage with an understanding of cadence in place. Imagine having twenty planning meetings for twenty iterations; with iterations operating at one-cadence, scheduling becomes less challenging.
• It builds muscle memory. When you have a rhythmic set of activities, it builds familiarity, and keeps the mind free of trivial (but, needed) details. When the mind is free of such, time is better spent on value-added work.
• There is a big reduction in coordination, which is an offshoot of the first advantage. Some critics of Agile say there is a large overhead involved, due to the need for coordination with short iterations. With cadence, this overhead is guaranteed to be less.
• Scaling the effort of Agile becomes easier. In scaled approaches, it’s usual to see multiple teams operating at the same cadence. Even if an iteration is cancelled or abnormally terminated, recovery is possible by going back to the cadence.
• As we saw earlier, with right cadence, the intensity of work remains even throughout a project.
  

More on the Topic of Cadence

As we reach closure of this article, I want to summarize the concept of Cadence used in flow- or iteration-based Agile with a video. It’s taken from ACP Live Lessons course. [Duration: 4m:26s]. This video uses a real-world example to explain the concepts I’ve written about above. For a better audio-visual experience, you may want to go full-screen with HD mode and plug-in your earphones.

Conclusion
The classical dance of Odissi starts with a solo form of pure-dance, where the performer emphasizes the execution aspect. It’s about knowledge, skills, dance patterns, and execution. The dancer, at this stage, excels with pure technical performance. In Agile methodology with daily cadence, the emphasis is also on execution–a bit of planning, a bit of design, a bit of development, a bit of testing, a bit of integration–daily. The individual developer is primarily involved in this technical work.

After the start, highlighting technical skills, we see the Odissi performer dancing with emotion, communicating feelings, and expressing nuance. Multiple dancers often come together at this point in the performance. In the context of Agile, within iteration (or flow) cadence, individuals come together to decide which items will be taken-up as they interact and communicate.

Next in the Odissi dance, it’s about group performance, or a team delivering together (i.e. they work on the whole drama part of the dance with a story). Similarly, in Agile, as the team comes together, delivery is made in release cadence. This can be after multiple iterations, every iteration, or on-demand. In most cases, these releases are given to the customer.

Finally, when pure-dance and dance with emotions combine with group-dance and delivery happens frequently, the Odissi dance becomes something else entirely. It is climatic, liberating, and often even stunning when this occurs. This stage is known as Mokshya in Odissi, meaning liberation or freedom.

In Agile parlance, this stage will be called a hyper-performing team, and it delivers highest-valued deliverables frequently, without interruptions. The team performs as a single, immutable unit, giving hyper-performances. While doing so, a constant pace can be maintained indefinitely. This is the essence of cadence.
 
* The opening photo of Odissi dance is by Bijay Biswal, who graciously agreed to share his ball-pen painting for this article and informed to be an honor that his painting is featured in the article.

—
This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away two years ago on June 11. He, along with my mother, introduced me to Odissi dance, taught me the importance of dance and music in our daily lives. It’s a tribute to them and their teachings. Men and women around the world have kept alive various forms of dance, which calms our minds and nourishes our souls. I take a bow.

--

This article was first published by MPUG.com on 29th June, 2021.

 
References:
[1] Online Course: PMI-ACP Live Lessons – Guaranteed Pass, by Satya Narayan Dash

[2] Online Course: PMI-ACP 21 Online Contact Hours, by Satya Narayan Dash

[3] Book: Kanban and Scrum, Making the most of both, by Henrik Kniberg and Mattias Skarin

[4] Book: I Want To Be An ACP, the Plain and Simple Way to be a PMI-ACP, 2nd Edition, by Satya Narayan Dash

[5] A Guide to Project Management Body of Knowledge (PMBOK), 7th edition, by Project Management Institute (PMI)

 

Earned Value Management (EVM) in Agile Development

In this article, we are going to explore Earned Value Management (EVM), a widely used traditional management technique, but we are going to look at it within the context of an Agile domain.

Let’s consider an example scenario. A product manager, who works for a large aircraft manufacturing organization in the United States, follows a hybrid model of development and, with his team, releases a new version of aircraft handling software every couple of weeks. At the start of each iteration, he may be unsure about the applicability of earned value analysis, measurement, and management within Agile. His main questions may be:

• How can we apply EVM while following an Agile approach? Is it natural?
• With frequent scope changes, how does one determine what to measure against?
• Scope change is also frequent on the iteration level! How can we incorporate EVM metrics in such cases?

To understand EVM, one needs to understand the concept of baseline, first and foremost. In EVM terminology, baseline is further defined as the performance measurement baseline (PMB). Let’s first define PMB, because, as I’ve seen, the lack of clarity regarding EVM is typically due to lack of PMB understanding. 

Performance Measurement Baseline (PMB)

The PMB is a virtual (not physical) baseline integrating scope, schedule, and cost baselines. In other words, PMB is the time-phased budget of authorized work for a project or program.

EVM is fundamentally based on this baseline–irrespective of chosen life cycle, be it predictive (Traditional), adaptive (Agile), or any other. It doesn’t matter how many iterations (or sprints, if in Scrum) you have or how frequently the scope changes. For EVM, it matters where and how you are setting your baseline. We will see shortly where the baseline is an Agile context. As EVM integrates scope, schedule, and cost, it’s quite a powerful technique. This is shown in the below figure.

 

Another issue occurs when management practitioners incorrectly interpret earned value as being business value. Earned value is not business value, rather it’s the value that you have earned in terms of money after completing the work. Hence, it’s actually a measure of work performance or performance against the set baseline or PMB.

With these fundamentals in mind, let’s now consider the foundational metrics in EVM. 

Foundational Metrics in EVM

The foundational metrics in traditional EVM are noted in the below table. I call them the foundational (or basic) metrics, because, based on these metrics, current and future performance metrics are derived.

As you go through the metrics in EVM, one key thing is to remember is this: everything is in terms of money. The budget, of course, will be in terms of money, and the work planned and work performed or executed, will also be in terms of money in this case.

We will look at the usage of these foundational metrics for Agile development shortly. Note that with these foundational metrics in place, we derive performance metrics of EVM.  

Current Performance Metrics in EVM

The current performance metrics used to calculate EVM are noted in the below table for a Traditional environment. I call these metrics current performance metrics, because the measurement happens on the status date, data date, or record date. The good news is, that these foundational metrics remain the same for Agile projects and/or programs.  Keep reading, as we are going to reuse these performance metrics in the next section.

It’s pertinent to note the behavior of SV and CV. If they are positive or negative, then the project or program is ahead of or behind schedule and cost, respectively. Similarly, if SPI and CPI are above or below 1.0, then the project or program is ahead of or behind schedule and cost, respectively. 

Using EVM in Agile Approaches

When using EVM in an Agile approach or environment, we circle back to the concept of baseline. In Agile projects, the baseline at the release level, not at an iteration level must be considered.

You may be wondering why. In Agile approaches, work is considered “done” at the end of each iteration (or sprint). While it’s true that story points are used to relatively estimate work items being taken-up, work is not considered to be fully “done” until the end of the iteration. If an item is not done, then it’s usually pushed into the next iteration. Hence, measurement during an iteration adds no value. This is because the work can’t be complete/done (or incomplete/not-done) mid- iteration.

If a story is complete, only then is it considered “done.” If a story is partially complete, (say only transition testing is remaining, then it’s not considered to be “done” at all). As you can see, it’s futile to have a baseline at an iteration level.

Are you wondering now how to calculate the performance measurement baseline (PMB) at a release level?

Simply add up the number of story points that you have planned for the release. While the PMB is at the level of the release, we do the measurement at the end of every iteration. In other words, our status date or data date is set for the end of the iteration. This is because, at the end of the iteration, we know the amount of work completed or “done.” And, this work counts towards velocity. Velocity, as explained in this article, also can inform the number of iterations in a release. You can decide to have measurement at the end of any iteration – iteration 1, iteration 2, and/or iteration-N.

A (product) backlog-based representation with earned value related calculations is depicted in the figure below.

As shown, the EV, PV, and AC values are calculated on the status/data date, which occurs at the completion of the iteration. The PMB is set for the release, and this also informs the budget at completion (BAC) for the release.

Next, we will consider the metrics associated with EVM in an Agile environment. 

EVM Metrics in Agile Approaches

The foundational EVM metrics used in Agile are noted in the below table with explanations. As you can see, the traditional metrics of EV, PV, AC, and BAC are also taken-up in Agile development; however, the explanation and understanding with respect to Agile contexts are different.

The values for PV, EV, and AC are calculated at the end of every iteration (you can set the status date as of the end of the concerned or considered iteration), whereas the BAC is determined at the release level. This is in sync with the backlog-based representation that we saw earlier.

The budget at completion (BAC) at the release level will be calculated as follows:

Budget at Completion (BAC)

= Total budget for the release

= Number of Items in the Release * Cost per backlog items (or cost per PBI)

For every item in the backlog (PBIs), cost is usually considered, which is one of the key product prioritization factors.

Now that we have the BAC, we can easily calculate the EV and PV, respectively with the below formulas:

First taking PV, the formula will be:

Planned Value (PV)

= Percentage of planned complete * BAC

= % of planned complete * BAC.

Earlier I said, PV, EV, and AC, etc. are calculated as of the status/data date or the iteration completion date. Considering an scenario where you have five iterations in a release and you are measuring at the end of the 2nd iteration, we’d see the following: case:

Percentage (%) of planned complete

= Iteration number / Number of iterations

= 2/5

= 40%

The formula for earned value (EV) will come out as shown below.

Earned Value (EV)

= Percentage of actual complete * BAC

= % of actual complete * BAC.

Why are we considering percentage of percentage of actual complete for EV? It’s because earned value is the value that you have earned by completing the work or having “done” the work.

To determine the percentage of actual completed work, you have to consider the stories that have been completed at the end of an iteration. Let’s say you have completed 40 story points worth of work out of 200 in a release, and you’re at the end of 2nd iteration. The percentage is calculated as follows:

Percentage (%) of actual complete

= Story points completed (or done) / Total story points

= 40/200

= 20%

I’ve summarized the calculations in the below table. 

So far, we have shown small examples with respect to BAC, PV, EV, and AC. Based on these metrics, we can easily calculate the current performance metrics of SV, CV, SPI, and CPI using the formulas mentioned in Table – 2.

For this purpose, let’s take an example from the course, ACP Live Lessons, Guaranteed Pass, to compute the associated metrics. A dedicated set of videos are available in the Live Lessons course.

An Example – EVM In Agile

A project is being released in an Agile mode. Below are the details for the project:

• Product Backlog = 500 story points
• In the first release = 200 story points
• Velocity = 25 points per iteration
• Cost per point = $1600
• At the end of 1st iteration, actual cost incurred was $30,000.
• At the end of 1st iteration, story points completed were 20 story points.

With this, we can determine the following.

• Budget at Completion (BAC)
• Number of Iterations
• Planned value per iteration (PV) and Earned Value (EV) for the first iteration
• Schedule Variance (SV) and Cost Variance (CV)
• Schedule Performance Index (SPI) and Cost Performance Index (CPI)

If you have understood so far, you can try it on your own and determine the values being asked in the above questions.

To confirm your understanding and reaffirm your answer, the solution is noted below.

Budget at Completion (BAC)

= Cost per point * Number of story points

= $1600 * 200

= $320,000

Total number of Iterations

= Story points in a release / Velocity

= 200 / 25

= 8

Percentage (%) of planned complete at the end of first iteration

= Iteration number / Total number of iterations 

= 1 / 8

= 12.5%

Percentage (%) of actual complete at the end of first iteration

= Total number of story points completed / Total number story points planned

= 20 / 200

= 10%

Now that we have the needed values, let’s calculate the other associated metrics of PV, EV, and AC.

Planned Value (PV) for the iteration

= % of planned complete * BAC

= 12.5% * $320,000

= $40,000

Earned Value (EV) for the iteration

= % of actual complete * BAC  

= 10% * $320,000

= $32,000

The actual cost (AC), as mentioned in the question

= $30,000.

With these calculations, we can now determine the current performance metrics of the project at the end of the first iteration.

Schedule Variance (SV)

= EV – PV

= $32,000 – $40,000

= – $8,000

Cost Variance (CV)

= EV – AC

= $32,000 – $30,000

= + $2,000

Look at Table – 2. One could say the release is behind schedule and under budget by looking at the performance metrics of SV and CV, respectively. This is because SV is negative (bad), whereas CV is positive (good).

Next, let’s determine the values for SPI and CPI.

Schedule Performance Index (SPI)

= EV / PV

= $32,000 / $40,000

= 0.8 

Cost Performance Index (CPI)

= EV / AC

= $32,000 / $30,000

= 1.07

Again, referring to Table – 2, you could say the release is behind schedule and under budget by looking at the performance metrics of SPI and CPI, respectively. This is because SPI is below one (bad), whereas CPI is above one (good). 

Representation in S-Curve

Like a traditional EVM, in Agile context, you can also depict the various EVM metrics in an S-curve. These curves are frequently used in many projects to depict the progress and status reporting. However, your perspective has to change/adapt for the Agile context.

An S-curve showing BAC, EV, PV, AC, SV, and CV is shown in the below figure. 

The BAC is at the release level. The PMB line is along the EV curve. Our status date or data date is at the completion of Iteration – 3, and, on this date, we are measuring the foundational metrics of PV, EV and AC, as well as the current performance metrics of SV, SV, and hence, associated SPI and CPI. When you combine this representation with estimated story points in the product backlog, you can have the release burn-up chart. 

Video – EVM in Agile

As we close, I want to summarize the foundations of EVM in Agile in the below video, taken from the course, ACP Live Lessons [duration: 13m:06s]. This video notes certain key points you should keep in mind when calculating earned value in an Agile domain. It also further explains the above S-curve. For the best experience, you may want to go full-screen in HD mode and plug-in your earphones.

With this, I believe, I leave you with the fundamentals of earned value management executed in Agile environments.

If you have comments, suggestions, or new ideas, please do share them below.

--

This article was first published by MPUG.com on 22nd September, 2020. This is a refined version.

References

[1] Course: ACP Live Lessons, Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] Book: I Want To Be A PMI-ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

[3] Course: ACP 21 Contact Hours, with Money Back Guarantee, by Satya Narayan Dash