Skip to main content

Author: Sreedhar Koganti

The Holy Grail of Agile (Scrum) Performance Management: AgileEVM at a Glance

To have a successful project, one needs to master and have a clear understanding of the project’s scope, schedule, and cost. Once you know them, the next challenge would be to know how to monitor the progress and performance of the project. Earned Value Management (EVM) is an industry validated technique used to measure project performance.

EVM provides a set of results that gives an objective insight into project performance. The Project Management Institute (PMI) has promoted it by including it as a standard in PMBOK guide.

EVM integrates technical performance, schedule, and actual cost to provide a metric for work completed. The single most important benefit of EVM is providing cost efficiency readings. These readings help provide the early warnings of performance problems while there is still time for corrective action.

What is AgileEVM?

Scrum framework has not provided any standard approach to measuring cost or performance. Here I am adapting a traditional EVM implication to Scrum framework in order to measure the performance.

AgileEVM is a term used by people that follow or bring EVM into the Agile world.

Related Article: EVM: Project Management With the Lights On!

The idea behind AgileEVM is to measure progress at the end of each sprint when actual velocity and actual costs are known. To measure AgileEVM, we need to have a minimum of 4 key values. They are:

  1. Actual cost of the project
  2. Estimated product backlogs
  3. A release plan, which provides information on the number of sprints 
  4. Velocity, to know how many points can be done in each sprint. Velocity can be measured in Story points, units, days, and work hours, etc. We will examine some of the core concepts, which help measure performance. In general, we can measure performance after every Sprint or while in the middle of the Sprint.

Common EVM Terminology

Before diving into the calculations, we need to have a common understanding of EVM terminology. 

Budget At Completion (BAC) = The budget assigned to complete the work

Planned Value (PV) = Expected % completed * BAC = Budgeted cost of work scheduled (BCWS)

Earned Value (EV) = Actual % completed * BAC = Budgeted cost of work performed (BCWP)

Actual Cost (AC) = Actual cost for the release (Cost * Total hours spent)

Cost Performance Index (CPI) = EV/AC

Schedule Performance Index (SPI) = EV/PV

Actual Percent Complete (ACP) = Story points completed/Total story points planned (Within the sprint calculation, we have to use points completed/points scheduled)

Expected Percent Complete (EPC) = Number of sprints completed/Total sprints planned

An Example of AgileEVM at Work

Let’s assume there is a need to develop a website, and let’ say after detailed discussions and brainstorming with the Product Owner and key stakeholders, we came up with the Product Backlog below.

Backlog List:


Once you know the backlogs, you need to determine how many story points each backlog gets and estimate the number of sprints. For this exercise, I made an assumption that the total number of story points was 272. Remember, story points always need to be converted into the number of work hours. There is no hard and fast rule for estimating the number of story points or relating the story points with the number of work hours.

One of the important key points here is, as an estimator, we need to estimate how many story points can be completed in each iteration (sprint) based on the people assigned to the project. In other words, we need to estimate the velocity of how many story points can be completed in each sprint. For our exercise, I estimate the velocity of each sprint is 17.

One last thing we need to know is the cost per point. The cost per story point can be derived by identifying the number of work hours of each story point, multiplied by the hourly cost. To keep things simple, the hourly cost can be calculated from the average cost of all the team members’ hourly cost. For the sake of the exercise, I will use each point’s cost as $1,600.

Based on the data that we have, let’s calculate BAC and number of sprints:

BAC = Cost per point * Total story points = 272 * 1600 = $435,200

No. of sprints = Total story points / Estimated velocity of sprint = 272/17 = 16

Measure Sprint Progress

Let’s assume we are at the end of sprint 1 and we wanted to measure the performance. To make things interesting, though initially we estimated each sprint velocity as 17, we will assume the team completed only 7 points in sprint 1. The table below shows the performance measure values at sprint 1. The calculations are based on formulas provided in the ground rules.

pmarticle05 30

By looking into the case study we can clearly say the project is behind schedule, as SPI is less than 1 (or EV < PV). Apart from burndown and velocity charts, we can also create EVM performance measure charts like PV vs EV, BAC vs EAC, etc. for readability, better understanding and for better reporting purposes.

pmtimes articlemay30

Common Questions About AgileEVM

There are some common questions that generally arise when we implement EVM in Agile (Scrum). Let’s look at some.

Regarding re-baseline: One very important concept that we need to remember is that Agile-Scrum allows changes to the backlog at the end of each sprint (iteration). To get the changes accounted, we need to re-baseline after every sprint occurs. In general, we need to re-baseline after a scope change, but in the Agile-Scrum world, we need to consider re-baseline after every sprint.

The AgileEVM calculation helps validate the release plan with these modified backlogs. This validation helps us to know whether we will be able to complete the work within the given schedule and budget.

When we need to plan sprints and BAC: All the initial ground work related to estimating the budget, sprints and points will be estimated in sprint 0. We carry this information and use it in the AgileEVM calculation between sprints or whenever we need to know the project performance.

Can I measure performance whenever I want or do I only need to calculate after each sprint? AgileEVM can be measured at any point in time. This means it can be measured at the end of each sprint or while the sprint is in progress.

Is this is the only way we can measure AgileEVM? No, this is only one of the standard approaches. There are a couple of other ways people use this, like measuring the cost by the number of work hours rather than story point.

In the above example, in order to make things simple, I measured the cost with the story point. To get the actual cost, one needs to consider cost per hour. This process will become a lot easier if we use a standard Agile Project management tool. At the same time, it’s good to know the internals.


AgileEVM helps us to know the Project performance accurately. This information helps us make better decisions on release. Remember predicting failures early is a success.

Scaling and Stabilizing Team Velocity in Agile Scrum Projects

In this article we will discuss why observing velocity in agile projects is important in addition to exploring ways to improve and stabilize team velocity.

What is Velocity in Agile?

In the Agile world, a velocity metric or chart helps to predict how much work the team can successfully complete in the given iterations (sprint). In other words, we can say it helps to track how much effort the team has put in completing the work in the given sprint.

koganti Oct1
Picture 1: Funny Velocity Chart with Team inside

The primary advantage of the velocity chart is that it helps to gage how much work the team can perform in the given iteration by comparing past iterations’ (sprints) velocity charts.

In general, we find people providing tips on how to improve team velocity. In this article, I am going to focus more on how to scale and stabilize the team velocity. If we find an effective team velocity, we can plan future sprints more easily. It also helps us to monitor and predict the team’s progress.

How to Scale or Stabilize Team Velocity:

We know by now that if we scale and stabilize the team velocity, it will help us plan future sprints easily and predict the team’s progress. The following are 7 important areas that we need to consider:

Clear User Stories

User Stories are meant to be simple to read: giving more clear information on user requirement and providing sufficient information on the business case. The reason the Agile world encourages User Stories with a specific format is because the format is meant to be easy to read and simple to understand, both for the development team and other stakeholders. We must keep that in mind and encourage it in developing more meaningful User Stories that provide more granular detailed information. If the User Stories are clear and easy to assess story points or estimate time, then it becomes much easier to the development team to come up with accurate story points. If the story points are accurate and precise, then the development team can reach their goals in the assessed time. This indirectly helps to have stabilized and predictable team velocity.

Define Team Roles and Avoid Changes in the Team

Your team should have a clear definition of their roles on the given tasks or backlogs. Make sure that there are as few changes in the team as possible. The reason is, whenever a team member adds to the team or moves away from the team, overall performance will be affected. Sometimes this effect is seen in more than two sprints (i.e., if the team uses two-week sprints). This, in turn, affects progress. Though we make all the arrangements and plans to keep the team stable, sometimes this is unavoidable. In order to have less effect on the velocity when the team member moves away, it’s always good to keep the rest of the team members engaged in all the areas of the project to make them familiar with the maximum number of possible modules. Another way is to keep a backup of one another and get the team familiar with others’ work in review. In order to have a stable velocity, we definitely need to give high priority to having a stable team.

Take Advantage of Retrospective

Although Retrospective is meant to discuss what went well and what can be improved, I would encourage teams to use Retrospective time to discuss how to scale or stabilize their velocity. This would consist of topics like how the team can improve coordination in completing tasks, successes and failures. It is also important to document and discuss how teams were able to complete the given work in time. This helps the team recap and follow the approach in future sprints. In the same way, if the team was having difficulty on a task, discussing how they can improve it in future sprints would definitely help in improving future sprint velocity. After Retrospective, the next sprint planning meeting will come. During your retrospective, the team can come to a consensus on the issues of how to improve or stabilize velocity. By using the agreed methods, the team can plan the coming sprint. This, in turn, helps to gain velocity in the coming sprint.

Always See the Big Picture in Planning

Proper, detailed and careful planning results in a successful sprint. This gives a clear definition of the desired outcome. In order to achieve it, we need to focus on three main areas. 1) Help the product owner in prioritizing and selecting what needs to be done in the given sprint, 2) Give the team a hand in discussing backlogs in detail, and 3) Make sure the team has a clear understanding of the accepted stories. This helps the team to provide accurate story points. By doing the above, you help your team develop a properly planned sprint. This indirectly helps in having predictable velocity for the given sprint. In the long run, this practice helps create a scalable and stable team velocity.

Eliminate Dependencies

Dependencies always delay the work of the team. I suggest to first start looking for dependencies in the User Stories. These help us know the internal and external dependencies. It’s best to select the stories where your team is most comfortable—whether in handling them together or one at a time. Also, look at the big picture and see if any other external dependencies will affect the sprint.


Establishing a proper CM process for the code and deliverable will improve the productivity of the team and eliminate issues. This, in turn, improves traceability. Automating QA helps improve the validation process of the developed product. In the same way, we can extend the automation process to build procedures. These steps help in reducing the known and unknown issues, as well as help to improve the development process, thus helping to scale or stabilize the velocity.

Finally, work on eliminating impediments. Impediments will most definitely affect velocity. One needs to understand the importance of it and put work into this area to achieve better velocity.


Scaling and stabilizing velocity always helps in improving project progress. The careful analysis or examination of velocity helps in predicting future sprints and may also provide some guidance on improvements. Predicting, scaling or stabilizing the velocity of a project is an ongoing process. One needs to learn it with experience. Finally, remember to document the observations in your projects; they may help in finding better approaches in the future.

Don’t forget to leave your comments below.

The Art and Science of Servant Leader in Agile Scrum world

In this article we will examine some of the concepts and background of Servant Leader. Discuss some well-known leadership styles and explain how the Servant Leader associated with them. Discuss the characteristics of Servant Leader that pertain to a Scrum Master.

One of the Key roles in Scrum is Scrum Master. The Scrum frame work has given a clear definition for Scrum Master. Scrum Master meant to be an Agile Coach and a Servant Leader. To have a successful Agile-Scrum project, Scrum Master should play an active role. To precisely say Scrum Master should be a Servant Leader. In order to know clear definition of Servant Leader, first we need to know who is a leader and what leader ship means.

The most challenging question is what is Leadership?

There are many definitions for Leader and Leadership. Many people described Leadership in different ways. The most common conclusive answer is, “Leadership is a process of social influence, which maximizes the efforts of others, towards the achievement of a goal”. My personal view and the most influential definition to me is “Leadership is an art and science of leading others to deliberately create a result that wouldn’t have happened otherwise.”

The reason I liked the idea of defining “Leadership is an art and science of leading”, is because I truly believe and also many scholars stated that Leadership has nothing to do with seniority, one’s position in the hierarchy, nothing to do with title, and most importantly it is not meant to be just management. 

The most commonly recognized qualities of leader are: Honesty, Ability to Delegate, Communication, Sense of Humor, Confidence, Commitment, Positive Attitude, Creativity, Intuition, Ability to Inspire, and Clear Vision. There are other qualities we often see in books are, Self-Awareness, Self-Direction, Ability to Motivate and Social Awareness etc.
A leader can have one or all the above qualities, but they choose to follow different management style to achieve results. In general the management styles are broadly defined as:

  1. Autocratic Leaders: Make decisions without consulting their team members, even if their input would be useful.
  2. Democratic Leaders: Make the final decisions, but they include team members in the decision-making process.
  3. Laissez-faire: leaders give their team members a lot of freedom in how they do their work, and how they set their deadlines.

I won’t say they are the only styles, but I would say these are popular styles. I am hoping I gave enough information on Leader and Leadership. Let’s switch the gears and discuss Servant Leader.

Background of Servant Leader:

The style and definition of Servant Leader has been introduced by Robert K. Greenleaf. I would say before he defined, it might be there but he gave a form and definition to it and made it popular. The idea of the servant as a leader came partly out of his own experience. Greenleaf at one place mentions as “the need for a better approach to leadership, one that puts serving others—including employees, customers, and community—as the number one priority. Servant leadership emphasizes increased service to others, a holistic approach to work, promoting a sense of community, and the sharing of power in decision making.”

The characteristics of the Servant-Leader from Greenleaf are: Listening, Empathy, Healing, Awareness, Persuasion, Conceptualization, Foresight, Stewardship, Commitment to the growth of people, Building community.

Servant Leader in Scrum:

Just to reiterate, in the beginning of article I mentioned that Scrum Master is a Servant Leader. Just keep that in mind. If one truly believes and understands the soul of leadership and the philosophy behind Servant Leadership we can safely say ScrumMaster/Servant Leader is an important and very interesting role in Scrum. In Scrum framework, Scrum Master acts as a servant leader that serves the product owner, team and organization.

How can a Scrum Master be a True Servant Leader?

To know the association, first we need to know some of the responsibilities of Scrum Master. They are:

  1. Responsible for making sure that the team lives by the values and practices the principles of Scrum.
  2. Scrum Master does anything possible to help the team perform at their highest level.
  3. The Scrum Master is also often viewed as a protector of the team.
  4. Involves in removing any impediments to the process and also in the Team.
  5. Facilitating meetings.
  6. Coordinating with Product Owner and the Team.
  7. Making sure that team doesn’t overcommit the work.
  8. Establishing clear communication channel between stakeholders, Team and Product Owner.
  9. Helps in reaching goals to deliver potential shippable product.
  10. Etc

Let’s also see some of the Key Characteristics of Servant Leader. They are: Awareness, Listening, Persuasion, Empathy, Healing, coaching etc.

If we look into the Scrum Master Responsibilities and characteristics, we can conclude that Scrum Master is a Servant Leader, and this kind of leadership style only can help in achieving better results in Agile environments.

A true leader will deal with the situation and uses expert judgment in taking decisions. In order to achieve above responsibilities, Scrum Master/Servant Leader should not stick to only one management style or philosophy. I meant to say depending on situation, Scrum Master should act as a Democratic Leader, Laissez-faire, and Autocratic Leaders etc. The Scrum Master/Servant Leader can only achieve above responsibilities by following different management styles in different situations.

Where Servant Leader stands in the Pyramid/Equilateral Triangle:

As pictures is worth of thousand words. I felt like explaining it with an example picture. Whenever we talk about Leader or Leadership, we find a picture and in that it will show Leader will be on the top of the PYRAMID and several layers will be represented below him, could be characteristics, organization structure etc.

In Scrum world, I would see Scrum Master/Servant Leader will be inside the Equilateral Triangle. Not on the Top of it.

sreedhar July23Picture 1 : Scrum Master/Servant Leader Equilateral Triangle

If you look at the picture 1, Product Owner (Stakeholders) is on one side, Team is on one side and Scrum Sprint is in another side. The Scrum Master/Servant Leader is inside. It’s the Scrum Master’s duty to keep all the sides and proportions are equal. Keep the balance between proportions. In order to achieve, Scrum Master need to follow all the Servant Leader principles, guidelines, characteristics etc. Scrum Master ultimate goal is to make sure the scrum team lives by the values, principles and practices the Scrum at all time, the only way Scrum Master could control is by live inside the boundaries and understand the philosophy of all the proportions. Throughout the article I am stressing Scrum Master is a Servant Leader, there is another term often we hear is “Scrum Master is an Agile Coach”. Coaching is one of the characteristic of Servant Leader. So Scrum Master needs to help the team and does anything possible to make the team perform at their highest level. To achieve this, Scrum Master needs to make sure that, there won’t be any impediments to reach the goals, to be a better communicator, be a better facilitator, make sure that team won’t overcommit, develop good harmony between product owner and the Team. Regarding picture, the only reason I kept more than two hands and two legs, just to show that Scrum Master should be capable to do more and to bring believability.


Scrum Master is a very key component in the Scrum Framework, one need to be a better agile coach or Servant leader to achieve goals and to deliver potentially a shippable product. Scrum Master is not a Project Manager, though he manages at some level; Scrum Master is a Leader with the capabilities and abilities to serve the Scrum Team as a Servant Leader.

Don’t forget to leave your comments below.