How Do I Apply Earned Value Management to Agile Projects?

Earned Value Management (EVM) gives you objective cost and schedule performance data. Agile gives you working software every sprint. Combining them means you can answer “are we on budget?” and “when will we finish?” with numbers instead of gut feel. Here’s how to make it work without turning your standups into status meetings.

The Core Problem

Traditional EVM assumes a fixed scope baseline (the Performance Measurement Baseline, or PMB). Agile assumes scope changes every sprint. If you force a fixed baseline onto a Scrum team, you’ll measure variance against a plan nobody believes in. The fix: re-baseline at sprint boundaries, but keep the math honest.

Define Your Value Unit

EVM needs a common unit of measure. In construction it’s dollars. In Agile, use story points or ideal days — whatever your team estimates in. Pick one and stick with it for the release.

• Planned Value (PV): Sum of story points planned for completed sprints. If sprint 1–3 committed to 40, 45, and 35 points, PV after sprint 3 = 120 points.
• Earned Value (EV): Sum of story points actually completed (done-done, accepted) in those sprints. If the team delivered 38, 42, and 30, EV = 110 points.
• Actual Cost (AC): Real cost incurred — labor, tools, infrastructure — for those sprints. Track in dollars or person-hours.

Now the indices:

CPI = EV / AC     (cost efficiency, unitless if EV and AC share units, else $/point)
SPI = EV / PV     (schedule efficiency)

If you track AC in dollars and EV in points, CPI becomes “dollars per earned point.” That’s fine — trend it sprint over sprint. A rising CPI means you’re getting cheaper per point (good) or cutting corners (bad). Context matters.

Forecasting: EAC and ETC

Estimate at Completion (EAC) tells stakeholders what the release will cost. Three common formulas, pick based on why you’re off track:

Scenario	Formula	When to Use
Typical variance continues	EAC = BAC / CPI	CPI stable, no root-cause fix in sight
One-time slip, future sprints on plan	EAC = AC + (BAC – EV)	Single sprint anomaly (illness, env outage)
Both cost and schedule slipping	EAC = AC + (BAC – EV) / (CPI × SPI)	Systemic issues, need recovery plan

BAC (Budget at Completion) = total planned points for the release × planned cost per point. Update BAC when scope changes — add/remove points, recalc.

Sprint-Level Mechanics

At sprint review, capture:

1. Committed points (PV for this sprint)
2. Accepted points (EV for this sprint)
3. Actual sprint cost — dev hours × loaded rate, plus any sprint-specific spend (licenses, cloud burst)

Roll up to release level. Plot CPI and SPI on a control chart with ±10% bands. If CPI drops below 0.9 for two consecutive sprints, trigger a retrospective focused on estimation accuracy or scope creep.

Handling Scope Changes

Agile welcomes change. EVM hates it. Compromise: every scope change (new story, split story, dropped story) adjusts BAC and PV immediately. Document the change, the reason, and the stakeholder who approved it. This gives you an audit trail and prevents “why did the baseline move?” questions later.

Tool tip: Jira + Tempo or Azure DevOps + Power BI can automate the rollup. Tag stories with release, sprint, and estimate. Pull AC from timesheets or payroll integration. Build the dashboard once; update it every sprint review.

What Not to Do

• Don’t track EV at the task level. Story-level is enough granularity.
• Don’t use hours remaining on tasks as EV. That’s burndown, not earned value.
• Don’t report CPI/SPI to stakeholders without context. “SPI 0.92” means nothing. “We’re 8% behind schedule because the API integration took two extra sprints; we’ve added a contractor for the next sprint” means everything.
• Don’t treat a sprint with zero accepted stories as EV=0 if the team did discovery work. Spike stories need a point value and a done definition, or exclude them from EV entirely and track separately.

Minimum Viable EVM for Agile

If this feels heavy, start here:

1. Track PV, EV, AC per sprint in a spreadsheet.
2. Calculate CPI and SPI each sprint.
3. Plot the trend.
4. Forecast EAC using BAC/CPI.
5. Share the chart at sprint review. Answer questions.

That’s it. No certifications, no heavy tools, no “EVM officer.” Just numbers that tell you whether your release plan is realistic — and if not, how unrealistic.