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

The Big Picture with Story Map in Agile Development

“I keep six honest serving-men,

They taught me all I knew,

Their names are What and Why and When,

And How and Where and Who.

I send them over land and sea,

I send them east and west,

But after they have worked for me,

I give them all a rest.”

– From the poem, “The Elephant’s Child,” by Rudyard Kipling

Long ago, in my childhood days, I was introduced to the fascinating world of poetry by my father, who brought a variety of poems and stories from writers and authors around the world to me. “The Elephant’s Child” was one of them.

This poem in particular has been used as a method. That is, the Kipling method. One of communication management, risk identification, charter preparation, and also, product development. With this method, one gets various ideas considering multiple aspects: What, Why, When, Where, Who, and How. It’s also known as the 5W1H method. In this article, we will learn about a technique called Story Mapping, where this method can be employed as an initiation point.

With the 5W1H method, when starting product development or creating a service or solution, one asks questions such as the following:

• What needs to be built?
• Why are we building it?
• For whom are we building?
• When will it be needed?
• Where does this fit in?
• How are the customers going to use it?

Jeff Patton, the creator of the User Story Mapping technique, explains the building of the map in six simple steps. They are:

• Frame the idea or problem
• Map the big picture
• Explore
• Slice out a release strategy
• Slice out a learning strategy
• Slice out a development strategy

The above 5W1H questions address the initial steps. It is important to remember that these questions get the conversations rolling. Shared conversations and shared understanding can then occur, as those aspects are what stories are mainly about.

Story Map Definition

As you may have noticed, this article is about Story Mapping, not User Story Mapping. There can be varieties of stories: spike stories, analysis stories, risk stories, and architectural stories, among others. I’ve seen all such stories being part of the map, and hence, will be using the term, Story Map.

Let’s begin with the definition of a story map. I'll define it as follows:

Story map is a grid-like graphical representation of epics and stories in a sequenced order based on their business value and the order in which the stakeholders will execute them. When read from left-to-right of the map, it tells a big story in a sequence of steps, whereas when read from top-to-bottom, it gives more details about each step.

After you have framed the idea or problem with the 5W1H questions, you can begin to build a story map at a very high level with the help of above definition.

The customer, user, or subject matter expert may tell the story of the product being built in a sequence of steps. Each step is written on a sticky note, index card, or electronic card horizontally (from left to right). Then, under each step, the details are written on another set of cards, and this time, placed vertically from top to bottom. This forms a grid-like structure as shown below. This is a story map.

In his book, Jeff Patton calls the steps from left to right, “Activities”. Under each activity, you have a set of “tasks”, which you get when you break-down or decompose the activities.

As shown, the story is told by a user from left-to-right in a sequence of steps—each step being an activity. This sets the narrative flow. Under each activity, we have a set of tasks decomposed from the respective activity, and they are placed vertically from top-to-bottom.

With this basic understanding, let’s go a bit deeper and understand the various components of a Story Map.

Going forward, I’ll be using terms such as Epics (in place of Activities) and Stories (in place of Tasks), to maintain consistency with an earlier article on Agile development. In the real world, it doesn’t matter which terminologies you use, if you understand the concept and can apply it while building your product or solution. 

Building Blocks in a Story Map

Personas

The story telling for a story map starts with the persona. Persona is usually taken for a user, but in this case, I’ve extended it to stakeholders. The persona is an imaginary representation of the stakeholder role used while describing a story. You may express this element as the needs of an imaginary stakeholder. The persona can have likes, dislikes, a job, and goals, among other aspects. A persona plays a role in the organization—the role is real, but the persona is not.

The epics are considered from the persona’s perspective. For example, the story explains how the stakeholder is going to use the product or solution. Comparing a story map to a human being, you can say the persona will act as the head of the story map. The first thinking part starts here.

For story mapping, there can be many personas – not just one. This is similar to a human being who grows with input from many. When working with personas, a variety of stakeholders in various roles should be considered, who will interact with the product being built.

Backbone

Without a spine, a human can’t function, and similarly, without a backbone, a story map can’t function. The backbone provides the minimum set of capabilities needed to deliver the product or solution or service. This can also be called the minimum viable product (MVP). The backbone usually consists of features and epics.

Walking Skeleton

Just below the backbone, we have the map’s body part. The body consists of the walking skeleton. Again, making a comparison to the human body, you can say the walking skeleton is the story map’s skeleton, too. Just like the human body’s skeleton, without the walking skeleton, the product would be non-functional.

The walking skeleton is the complete set of end-to-end functionalities that make the product or solution acceptable. This part of the story map’s body usually consists of stories, including the user stories. This set of stories make the product minimally functional, and hence, can be called the minimum marketable features (MMF).

Under each story of the walking skeleton, you can have more stories arranged vertically. Higher priority stories will be at the top, whereas lower priority ones will be at the bottom.

When you combine the personas, the backbone, the walking skeleton, and the additional stories below the walking skeleton, you get the Story Map, as represented in the below figure.

The stakeholder starts telling the big story in a sequence of steps, which are represented as epics. This constitutes the backbone. While building the backbone, the principle of “mile wide, inch deep” or “kilometer wide, centimeter deep”, as Jeff beautifully puts it, is followed. It means we get to the end of the big story, before diving deep into the details.

The walking skeleton is below the backbone. When you decompose the epics in the backbone, you get the stories in the skeleton—ones that make the product minimally functional. Below the walking skeleton you have more stories, which are ordered.

Release Planning with a Story Map

After you have placed the epics, stories, and features in the story map based on the team’s capacity to deliver, releases can be determined. This is where the release strategy is sliced out from the story map.

As we already know, the backbone includes all the absolute essential parts of the product. These are items that you just can’t prioritize because they have to be in the product. Next to the backbone, we have the walking skeleton, which has the minimum marketable set of features. Hence, our first slice for the release consists of these two, and possibly some more stories, below. In the next slice (for another release), we can take more stories and create another release, and so on. This is shown in the figure. 

As you can see, in the first release we have the backbone and stories from the walking skeleton, along with one story below the backbone. In our second release, we have more stories taken, which are from below the backbone. Remember that these stories are ordered based on their business value.

Story Map vs Product Backlog

At this stage, you may be wondering why one should go for a Story Map rather than a Product Backlog?

After all, the product backlog also has all the epics, features, and stories in a single file. It can also have release slices. There are quite a few differences between the two, but I’ll note the most significant ones:

• While working with the product backlog, it’s easy to get lost in the details. Team members will be working on tasks, but they don’t see the big picture. You can literally miss the forest for the trees! With a story map, all members of the team see the big picture. This, in my view, is the most significant benefit of a story map over a product backlog.
• The story map is a two-dimensional visual structure, whereas the product backlog is a one-dimensional flat structure. Story mapping, on its own is also a prioritization technique—it’s just that it is done in a visual way.
• Dependencies can’t be easily shown in a product backlog as long as it’s a flat one, whereas dependencies can be represented visually and more clearly with a story map.

So, which should one use?

Note: You can learn the various differences between Story Map and Product Backlog in the below detailed post.

Agile Asanas: Story Map Vs. Product Backlog - The Differences 

The primary idea behind telling stories is communication. As noted earlier, it’s about shared conversations and shared understanding. You may think of using both the story map and product backlog in a single map, which is shown in the below figure.

The product backlog is just below the story map with a set of index cards or sticky notes, which are the backlog items. When needed, you can pull the prioritized ones into the story map. Don’t just go by the lumped-up cards in the backlog. Remember, you can order them as well.

It’s up to you as the Product Manager or Product Owner in consultation with your Project Manager and team members to decide which one best works for the team.

At this stage, it’s pertinent to note that like a Product Backlog which is never complete, a Story Map is also never complete. When new feature requests come up or enhancement requests are made, you can add, arrange, and order them within the story map.

A Practical Story Map

Let’s look at a real-world example to understand story mapping further. I’ll use my previous example of a flight ticket reservation portal, where I had explained various types of stories.

We will first start with the possible stakeholders (personas) who will be using this portal:

• Normal Traveler
• Business traveler
• Frequent Flier
• Booking Agent
• Vacation Traveler
• … you can add more.

You need not work on all of them, but can take just one to build the MVP consisting of the backbone and walking skeleton. For our example, let’s take the “Business Traveler.”

Considering the business traveler, we need to determine the big story in a sequence of steps. These steps will form the backbone or set of epics. These epics, when broken down, will provide the stories, which are listed next to them.

The epics are noted in the below table. Can you think of the associated possible stories?

Go ahead and try it.

The associated stories for the epics are noted in the below table. Your answer may vary, but you’re right if you tried to break-down and get to the related stories.

The above stories can be put in the usual story format. For example, you can say: “As a business traveler, I want to register via e-mail, so that I can sign-up for the portal.”

I’ve also noted the epics in the above table in single words. Search for a flight is simplified to “SEARCH,” select a flight becomes “SELECT,” and so on. This is for simplicity and to keep our high-level goals focused. When we take these epics and put them as a sequence of steps for the business traveler, we will get the following figure.

As shown, the story of a business traveler using the portal listed horizontally in a sequence of steps. The traveler will first sign-up, then search for a flight, and then select the flight. The traveler will pay for the tickets, and finally, close-out his/her interaction with the portal. These steps form our backbone.

Next, we will take the first big activity or epic, “SIGN-UP,” and arrange the stories associated with it vertically, as shown below. If you created your own stories, go ahead and put them below the respective epics within the structure of the backbone. This results in the walking skeleton and more stories below it.

Next, we slice out the releases from the map.

• For the backbone, we will have SIGN-UP, SEARCH, SELECT, PAY, and CLOSE.
• For the walking skeleton, we will have “new user registration” and “log-in” from “Sign-up,” “search by journey start/end dates” from “Search,” “Choose by shortest flight duration” from “Select,” “pay via credit card” from “Pay,” and “logout” from “Close.”

Your first release slice may look differently depending on the epics and stories you have chosen to start with. If your team has the capacity, take more. If this is the case, when you slice out the first release, it will result as shown below.

For subsequent releases, you and your team can decide which other stories are to be taken up.

That’s it! If you have understood so far and are able to slice out your first few releases in the map, you have understood the concept of story mapping well. It’s a long-read. But, I believe, if you have read it, worked on it, and gone through it honestly, it’s time to take a rest, as the poem I opened with says.

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

This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away last year on June 11. I miss him every day and feel his absence. He first introduced me to the world of poetry, stories, and books, so this is a tribute to him and his teachings.

--

This article was first published by MPUG.com on 23rd June, 2020. 

References:

[1] User Story Mapping – Discover the Whole Story, Build the Right Product, by Jeff Patton with Peter Economy

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

[3] The PMI Guide to Business Analysis, by Project Management Institute (PMI)