HKSM

Earned Value Analysis is a quantitative technique that compares planned value, earned value, and actual cost to gauge schedule and cost performance and to forecast outcomes. In Scrum/SBOK, it can be applied at release or sprint level by mapping backlog value or story points to a cost baseline and using accepted work only.

Key Points

• Tool and technique for monitoring and controlling progress using PV, EV, and AC with variances and performance indexes.
• Works well in Scrum when computed at the release level or during Sprint Reviews using only done and accepted backlog items.
• Translates agile estimates (story points or relative value) into monetary value via a baseline budget to compute EV and PV.
• Provides schedule and cost signals through SV, CV, SPI, and CPI, and forecasts like EAC, ETC, and VAC.
• Supports Product Owner decisions on scope, budget, and release timing without breaking time-boxes.
• Should be paired with empirical measures such as velocity, burnup/burndown, and Definition of Done for accuracy.

Purpose of Analysis

Use Earned Value Analysis to objectively understand whether the release or sprint is delivering as planned and within budget. It informs trade-offs among scope, schedule, and cost, and provides early warning so the Scrum Team and Product Owner can adapt plans, manage risks, or re-baseline when appropriate.

Method Steps

• Establish a baseline: define total budget at completion (BAC) for the release and a planned delivery curve across sprints.
• Choose a valuation approach: convert story points or backlog value to money (e.g., BAC divided by total planned points).
• Collect actuals for the current cutoff: accepted user stories (per Definition of Done) and actual cost to date (labor and other spend).
• Compute EV as the monetary value of accepted work, PV as the planned value by this date, and AC as actual cost incurred.
• Calculate variances and indexes: SV = EV − PV, CV = EV − AC, SPI = EV ÷ PV, CPI = EV ÷ AC.
• Forecast outcomes: EAC (common model = BAC ÷ CPI), ETC = EAC − AC, VAC = BAC − EAC.
• Review results in a Scrum event (e.g., Sprint Review or Release Planning), discuss options, and update the release plan or backlog.

Inputs Needed

• Release Plan and sprint-level plan showing intended scope delivery over time.
• Product Backlog estimates (story points or other relative sizing) and acceptance criteria.
• Budget at Completion (BAC) and cost assumptions (e.g., cost per story point or team burn rate).
• Completed and accepted items, verified against the Definition of Done.
• Actual cost records to date (team labor, vendors, tools).
• Schedule/calendar data to determine the planned value at the current point in time.

Outputs Produced

• Schedule Variance (SV) and Cost Variance (CV).
• Schedule Performance Index (SPI) and Cost Performance Index (CPI).
• Forecasts: Estimate at Completion (EAC), Estimate to Complete (ETC), and Variance at Completion (VAC).
• Updated release forecast and recommended scope, budget, or timing adjustments.
• Visuals and trends (e.g., EVM charts) for stakeholders.

Interpretation Tips

• SPI less than 1.0 indicates behind plan; CPI less than 1.0 indicates a cost overrun.
• Look for trends across several sprints; early sprints can be volatile while the team stabilizes.
• Use accepted work only; partially done items distort EV and hide risk.
• Re-baseline BAC and PV when scope changes materially to keep insights meaningful.
• Combine with velocity, burnup, and risk data to guide Product Owner decisions rather than micromanaging the team.

Example

Assume a release with BAC = $200,000 and total planned story points = 200 (implying $1,000 per point). By the end of Sprint 4, the plan (PV) was 80 points and the team actually accepted 70 points; actual cost (AC) to date is $85,000.

• PV = 80 × $1,000 = $80,000; EV = 70 × $1,000 = $70,000; AC = $85,000.
• SV = EV − PV = −$10,000; SPI = EV ÷ PV = 0.875.
• CV = EV − AC = −$15,000; CPI = EV ÷ AC ≈ 0.82.
• EAC (BAC ÷ CPI) ≈ $200,000 ÷ 0.82 ≈ $242,000; VAC = BAC − EAC ≈ −$42,000.
• Interpretation: behind plan and over budget; consider scope trade-offs, risk response, or re-baselining with the Product Owner.

Pitfalls

• Mixing units (e.g., EV in points and AC in dollars) without a clear conversion to monetary value.
• Counting partially completed stories, which inflates EV and masks risk.
• Using EVA to manage individuals rather than to inform product-level decisions.
• Failing to re-baseline after significant scope change, making metrics misleading.
• Overconfidence in precise numbers when actual cost tracking or acceptance data is weak.
• Breaking time-boxes to chase metrics instead of using insights to adjust scope or expectations.

PMP/SCRUM Example Question

A Scrum Team reviews a release at the end of Sprint 3. PV = $120,000, EV = $100,000, and AC = $110,000. What is the best next step?

1. Extend the sprint by one week to improve SPI.
2. Ask developers to work overtime until EV matches PV.
3. Discuss scope and release options with the Product Owner using CPI and SPI trends.
4. Stop using Earned Value Analysis because Scrum relies only on burn charts.

Correct Answer: C — Discuss scope and release options with the Product Owner using CPI and SPI trends.

Explanation: EVA indicates both schedule and cost pressure; in Scrum, respect time-boxes and use the data to make product-level decisions such as re-scoping, re-baselining, or adjusting release expectations.