Earned Value Analysis Results

Earned Value Analysis Results are the compiled findings from comparing planned value to value actually earned and actual cost. They include variances, performance indices, and forecasts that show cost and schedule health for a Scrum release or project. In SBOK Scrum, these results guide inspect-and-adapt decisions in reviews, retrospectives, and release planning.

Key Points

  • Output of Earned Value Analysis that consolidates PV, EV, AC, CV, SV, CPI, SPI, and forecasts such as EAC and VAC.
  • Calculated at release or project level, often mapping value to epics or user stories using story points or budgeted cost.
  • Relies on Definition of Done so only completed increments earn value.
  • Used by Product Owner and Scrum Master to re-forecast scope, schedule, and funding.
  • Feeds Scrum processes such as Demonstrate and Validate Sprint, Retrospect Sprint, and Conduct Release Planning.
  • Supports transparent stakeholder reporting with trends and threshold-based alerts.

Purpose

The purpose is to quantify how the initiative is performing versus plan in terms of cost and schedule, enabling objective, data-driven decisions. It provides early warning when delivery is off track and offers a basis to re-plan scope, budget, and timelines.

In Scrum, these results complement velocity, burn charts, and stakeholder feedback to balance value, cost, and timing while preserving agility.

Key Terms & Clauses

  • Planned Value (PV): Authorized budget or value planned to be delivered by a given date.
  • Earned Value (EV): Budgeted value of work that meets Definition of Done.
  • Actual Cost (AC): Cost actually incurred to deliver the earned value.
  • Cost Variance (CV): EV − AC; negative indicates over budget.
  • Schedule Variance (SV): EV − PV; negative indicates behind schedule.
  • Cost Performance Index (CPI): EV ÷ AC; less than 1.0 means cost inefficiency.
  • Schedule Performance Index (SPI): EV ÷ PV; less than 1.0 means schedule slippage.
  • Estimate at Completion (EAC): Forecast of total cost; common form is BAC ÷ CPI when performance is expected to continue.
  • Variance at Completion (VAC): BAC − EAC; negative suggests an overrun.
  • Baseline: Release plan scope, budget, and timing used for PV calculations.
  • Data date: The cut-off date for measurement each sprint or release checkpoint.
  • Definition of Done (DoD): Governs when EV can be claimed for a backlog item.

How to Develop/Evaluate

  • Establish a release baseline by mapping PV to epics/user stories using either story points monetized or budgeted cost per item.
  • Fix a data date (e.g., end of each sprint) and capture AC from tooling or finance.
  • Determine EV only for work that meets DoD; partial work does not earn value.
  • Compute CV, SV, CPI, SPI and produce simple trend charts across sprints.
  • Forecast EAC and VAC using agreed formulas; note assumptions behind each forecast.
  • Review thresholds (e.g., CPI or SPI < 0.9) and flag items requiring management attention.
  • Validate results with the team and Product Owner to confirm completeness and context.

How to Use

During Demonstrate and Validate Sprint, present trends to stakeholders alongside increments and burn charts to discuss scope trade-offs or funding needs. In Retrospect Sprint, analyze root causes and identify process improvements that may recover performance.

In Conduct Release Planning, use the results to update the release roadmap, adjust backlog ordering, and re-negotiate scope. For multi-team efforts, share results in Scrum of Scrums to coordinate cross-team impacts and dependencies. Update the risk register and impediment log when indicators breach agreed tolerances.

Example Snippet

By the end of Sprint 4 (data date): PV = $80,000, EV = $70,000 (only Done items), AC = $90,000.

  • CV = EV − AC = $70,000 − $90,000 = −$20,000 (over budget).
  • SV = EV − PV = $70,000 − $80,000 = −$10,000 (behind schedule).
  • CPI = EV ÷ AC = 0.78; SPI = EV ÷ PV = 0.88.
  • Assuming BAC = $200,000, EAC ≈ BAC ÷ CPI = $256,000; VAC = BAC − EAC = −$56,000.

Action: Product Owner discusses scope reduction or additional funding; Scrum Master investigates impediments and supports improvement actions in the next sprint.

Risks & Tips

  • Risk of counting partially done work; enforce DoD to avoid overstating EV.
  • Over-precision can obscure insight; keep calculations lightweight and focus on trends.
  • Story points must be consistently valued if used to derive PV/EV; avoid changing scales mid-release.
  • Do not use EVM to micromanage individuals; apply at release or team level.
  • Combine with qualitative feedback and product value metrics to avoid cost-only decisions.
  • Agree on alert thresholds and actions so teams know how results will be used.

PMP/SCRUM Example Question

During Sprint Review, the team reports CPI = 0.80 and SPI = 0.90 for the release. What is the best next step for the Product Owner?

  1. Extend the current sprint by one week to recover schedule.
  2. Update the release forecast and discuss scope trade-offs or funding options with stakeholders.
  3. Change the story point scale immediately to improve CPI and SPI.
  4. Ask the team to work overtime to increase EV next sprint without changing scope.

Correct Answer: B — Update the release forecast and discuss scope trade-offs or funding options with stakeholders.

Explanation: EVM results indicate cost and schedule pressure; the Product Owner should re-plan at the release level with stakeholders. Extending sprints, changing estimates, or mandating overtime are not aligned with Scrum and do not address the root issue.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Seven sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Launch your career!

HK School of Management offers training in project management, job-search strategies, and career growth. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More