Back to PMI Agile Certified Practitioner (PMI-ACP)

Agile EVM (Earned Value Management)

Evaluates project performance and progress in an agile context.

Agile EVM (Earned Value Management) is a project management technique which measures the performance and progress of a project in an objective manner. It evaluates both the value of work accomplished compared to the original planned costs and the actual cost to accomplish the work from financial perspective.
5 minutes 5 Questions

Agile Earned Value Management (Agile EVM) adapts traditional EVM to fit agile project approaches. It focuses on tracking project health through measuring value delivered across iterations or sprints. Agile EVM leverages agile artifacts like product backlogs and burndown charts to calculate earned …

Concepts covered: Incremental Delivery, Velocity, Planning and Monitoring Iterations, Estimation Techniques: Story Points and Ideal Time, Burn Down Chart, Agile Release Planning, Tracking Actual Cost, Budget at Completion, Relative Sizing/Story Points, Financial Analysis Techniques: NPV and ROI

Test mode:
Start practice test
PMI-ACP - Agile EVM (Earned Value Management) Example Questions

Test your knowledge of Agile EVM (Earned Value Management)

Question 1

You are the scrum master of team Hercules, which has a consistent historical velocity of 40 points per sprint. Recently the team incorporated automated testing, which they predict will increase the velocity to 50 points per sprint. The product owner comes to you with a new project of 200 points. How many sprints should you estimate for the new project?

Correct Answer: The project should take approximately 4 sprints if the velocity increase is sustained.

Initially, Team Hercules was having a velocity of 40 points per sprint. Post incorporation of automated testing, their velocity increased to 50 points per sprint. Now, let's take the new project which involves 200 points. If the team continues with their increased velocity rate of 50 points per sprint, then logically it would take Team Hercules around 4 sprints to accomplish the 200 points project ((200 points / 50 points per sprint = 4 sprints). So, the answer 'The project should take approximately 4 sprints if the velocity increase is sustained' is the most accurate. Now, let's clear up on the alternatives as well. The answer 'The project should take exactly 4 sprints' is slightly incorrect because it assumes no variability in the process which in real scenarios is rarely the case. As for 'The project should take exactly 5 sprints', this answer doesn't take into account the increased velocity due to automated testing. Finally 'The project should take less than 4 sprints' is incorrect, because even with the increased velocity after incorporating automated testing, we can't complete the project in less than 4 sprints.

Question 2

You’re the project manager of a mobile app development project which had initially a budget of $550,000. The development is 40% complete but the expenses already hit $250,000. If you continue spending at this pace, what will the budget at completion be?

Correct Answer: $625,000

The project is 40% complete, and already $250,000 has been spent. This implies that the rate at which the money is being spent is $250,000 / 40% = $625,000 for 100% completion. Therefore, if the project continues at this pace, the total budget at completion will be $625,000. The options $600,000, $575,000, and $650,000 are incorrect as they do not match the calculated value.

Question 3

The team's burn-down chart indicates a consistent downwards trend, but the product is not ready by the end of the sprint. As a Scrum Master, what is a possible explanation for this?

Correct Answer: Tasks were probably marked as done before they were fully completed or tested.

In Scrum methodologies, when the burn-down chart shows a consistent downward trend, it indicates that tasks are being completed. However, if the product is not ready by the end of the sprint, it's likely due to tasks being marked as 'done' prematurely. This often occurs when tasks are not fully completed or tested before being marked as 'done', causing discrepancies between the chart and the actual state of the product. The other answers could potentially be factors, but they would likely be reflected in the burn-down chart. If the team wasn't taking tasks seriously or were misreporting progress, the chart would likely not show a steady downward trend. Similarly, unclear requirements from the Product Owner could affect task completion, but this would generally result in a fluctuating burn-down chart, rather than a consistent downward trend.

More Agile EVM (Earned Value Management) questions
101 questions (total)
Start 100 question test