The Discipline of Delivery · companion to Chapter 10
Earned Value Management
PV, EV and AC in both waterfall and Scrum — and the two numbers that tell you whether recovery is a plan or a fantasy.
Earned Value Management — Mastery
The tracking layer. One product — Project Atlas — carried through both Waterfall and Scrum, so you can see the engine is identical and only "done" changes.
Where this sits. EVM comes after you have a baselined plan — a WBS, estimates, a schedule, and a budget. It measures performance against that baseline. If you haven't built the plan yet, start with the WBS & Scheduling chapter; if you don't know your budget mechanics, start with Financials.
💡
Why software needs EVM more than most
The cure for "90% done for three months"
Software has a unique disease: a feature is "almost done," and it stays almost done forever — because the last 10% (edge cases, integration, bugs) is the hard 90% of the effort. Classic tracking compares budget burned vs. money spent and is blind to this. If you've spent 50% of the budget, are you 50% done? In software, almost never — you could be 70% done or 30% done and the spend looks identical.
EVM fixes this by forcing a third measurement: the value of work that is genuinely, verifiably complete — merged-and-tested code, or accepted user stories, never "I'm nearly there." That single discipline is what makes every metric downstream trustworthy.
🔢
The three numbers everything is built from
Learn these three; the rest is arithmetic
PV Planned Value
Budgeted value of work scheduled to be done by now.
BAC × planned %
BAC × planned %
EV Earned Value
Budgeted value of work actually completed & verified.
BAC × verified %
BAC × verified %
AC Actual Cost
What the team has actually cost — salaries, contractors, licenses.
from finance
from finance
BAC = Budget at Completion = the total approved budget. For Project Atlas, BAC = $400k.
The one idea that makes EVM work
EV is valued in budgeted dollars, not what the work actually cost. If a module was budgeted at $20k and you finish it, you earn $20k of value — even if it actually took $30k of engineer time. The extra $10k shows up as a cost problem (in AC), not as bonus progress. This separation is the whole point: it lets you tell apart "we're behind schedule" from "we're over budget" — two problems with completely different fixes.
🧭
The design of this chapter
We check in on Atlas at the halfway point — end of month 5 (Waterfall) or end of sprint 5 (Scrum). The two models are set up to land on identical dollars — PV $200k, EV $160k, AC $200k — so you can see for yourself that the metrics are model-agnostic. Only the definition of "done" differs. Explore Waterfall and Scrum, then hit Metrics to run the numbers, and Calculator to try your own.
🏛️
Waterfall — value from completed WBS phases
"% complete" = sum of finished phases, weighted by budget
In Waterfall, work is a WBS of phases, each with a budgeted slice of the $400k. Earned Value is the budget weight of the phases genuinely finished — not phases "in progress."
| Phase | % of budget | Planned done by M5? | Actually done by M5? |
|---|---|---|---|
| Requirements | 10% | ✅ | ✅ |
| Design | 20% | ✅ | ✅ |
| Development | 40% | half (20%) ✅ | partial (10%) ⚠️ |
| Testing | 20% | not yet | not yet |
| Deployment | 10% | not yet | not yet |
| Cumulative | — | 50% planned | 40% actual |
$200k
PV = 50% planned × $400k
$160k
EV = 40% verified × $400k
$200k
AC = timesheets + contractors
We planned to be through design + half of development, but development hit integration trouble — so only ~a quarter of dev is truly done, yet we've already burned the full $200k we expected to spend by now.
🌀
Scrum — value from accepted story points
Same product, same answer — only "done" is defined differently
In Scrum, scope is a product backlog in story points. The release backlog at baseline = 800 points (the BAC analog). At $400k, that's $500 per point.
PV
Points planned complete by now (from the release plan).
EV
Points actually accepted — meeting Definition of Done, demoed, signed off. Work in progress earns nothing.
AC
Actual team burn — run-rate × sprints elapsed.
| Points | × $500/pt | = Dollars | |
|---|---|---|---|
| Planned by end of sprint 5 | 400 pts | $500 | PV = $200k |
| Actually accepted (done-done) by sprint 5 | 320 pts | $500 | EV = $160k |
| Actual cost (5 sprints × $40k run-rate) | — | — | AC = $200k |
The dollars land identically to Waterfall — PV $200k, EV $160k, AC $200k. That's deliberate: it proves the metrics are model-agnostic. The only thing that changed is how you measure "done": completed WBS phases vs. accepted story points.
Crucial Scrum rule: EV credits only accepted stories. A story that's "code complete but not tested/accepted" earns zero EV. This is Scrum's built-in cure for the 90%-done lie — done is binary and externally verified at sprint review.
⚖️
The Scrum tension interviewers probe
Classic EVM assumes fixed scope; Scrum embraces change
Baseline a release backlog, run EVM against it, then re-baseline for the next release. Within a release, scope is stable enough for the math to mean something.
When the Product Owner adds scope, BAC and PV are reset on a new baseline. You report "against release-2 baseline" so trends stay honest. In Waterfall, re-baselining is a heavyweight change-control event; in Scrum it's routine.
Velocity already counts only accepted stories, which is why Scrum and EVM fit nicely — Scrum hands you a clean, verified EV every sprint at no extra cost.
Dropping that term, plus "I'd track CPI/SPI at the release level while teams stay iterative underneath," signals you understand both worlds.
One-liner to use: "In Scrum I run EVM at the release level off a baselined backlog, credit earned value only for accepted stories, and re-baseline each release — so leadership gets a portfolio-level cost-and-schedule view while the teams stay fully Agile."
📊
The metrics — identical for both models
Plug in PV = $200k, EV = $160k, AC = $200k, BAC = $400k
Variances — subtract. Positive = good.
Schedule Variance
SV = EV − PV = 160 − 200 = −$40k
Behind schedule by $40k of work.
Behind schedule by $40k of work.
Cost Variance
CV = EV − AC = 160 − 200 = −$40k
Over budget by $40k for the work done.
Over budget by $40k for the work done.
The 2×2 that says it all
CV > 0 (under budget)
CV < 0 (over budget)
SV > 0
(ahead)
(ahead)
🟢 Ahead & cheap — ideal
🟡 Ahead but burning cash
SV < 0
(behind)
(behind)
🟡 Behind but frugal
🔴 Behind and over — Atlas is here
Indices — divide. Above 1.0 = good.
Schedule Performance Index
SPI = EV / PV = 160 / 200 = 0.80
Running at 80% of planned pace. In Scrum this is velocity attainment — 320 of 400 planned points = 0.80.
Running at 80% of planned pace. In Scrum this is velocity attainment — 320 of 400 planned points = 0.80.
Cost Performance Index
CPI = EV / AC = 160 / 200 = 0.80
80¢ of value per $1 spent. The king metric — on software it tends to stay flat or worsen after the ~15–20% mark.
80¢ of value per $1 spent. The king metric — on software it tends to stay flat or worsen after the ~15–20% mark.
📈
Forecasting — where Atlas actually lands
The part executives care about most
| Metric | Formula | Atlas value | Reading |
|---|---|---|---|
| EAC | BAC / CPI | 400 / 0.80 = $500k | Realistic final cost |
| ETC | EAC − AC | 500 − 200 = $300k | Cash still needed |
| VAC | BAC − EAC | 400 − 500 = −$100k | Projected overrun |
| TCPI | (BAC−EV)/(BAC−AC) | 240 / 200 = 1.20 | Efficiency needed to save the budget |
TCPI is the lie detector. We've been running at CPI 0.80, and TCPI says we'd now need to run at 1.20 to still hit $400k. A team stuck at 0.80 will not flip to 1.20. Translation: the original budget is gone — re-baseline and escalate now, at the halfway point, not at delivery.
🎯
Three EAC variants — pick by situation
| Formula | Use when… |
|---|---|
| EAC = BAC / CPI | Past cost performance will continue — most common, most honest default |
| EAC = AC + (BAC − EV) | The overrun was a one-off; remaining work will hit budget |
| EAC = AC + (BAC − EV)/(CPI × SPI) | Both cost and schedule pressure will persist — most pessimistic |
🗺️
Waterfall ↔ Scrum mapping
The table to memorize
| EVM concept | Waterfall (Atlas) | Scrum (Atlas) |
|---|---|---|
| BAC | Total project budget ($400k) | Release scope: 800 pts / $400k baseline |
| Unit of progress | Completed WBS phases, budget-weighted | Accepted story points (Definition of Done) |
| PV | Budget scheduled by this date | Points planned by this sprint |
| EV | Value of phases completed | Points accepted × $/point |
| AC | Timesheets + contractor + license | Team run-rate × sprints elapsed |
| SPI | Schedule adherence | Velocity attainment |
| CPI | Cost efficiency | Cost per accepted point vs. baseline |
| Re-baselining | Formal change request, rare | Expected — per release / PI |
| "% complete" risk | Optimistic phase reporting | WIP counted as done (avoid) |
⚠️
The hard part: measuring "% complete" honestly
Every number downstream is fiction if EV is fiction
| Method | How it credits EV | Best for |
|---|---|---|
| 0/100 | Nothing until the item is fully done | Scrum stories, small tasks — the safest default |
| 50/50 | 50% on start, 50% on completion | Medium Waterfall work packages |
| Milestone / weighted | Credit at defined checkpoints | Long phases with module milestones |
| % effort (avoid) | Self-reported % | Danger where the 90%-done lie lives |
Scrum's Definition of Done is effectively a strict 0/100 rule — which is exactly why Agile EVM tends to be more trustworthy than self-reported Waterfall progress.
🚧
Limitations to name in an interview
What EVM can't do
SV/SPI are in dollars/points, not time — and SPI drifts to 1.0 near the end (fix: Earned Schedule)
Garbage in, garbage out — optimistic % complete = lying metrics
No quality/value signal — you can be green and still shipping the wrong thing
Diagnostic, not causal — tells you that you're behind, not why
What it does brilliantly
Separates a schedule problem from a cost problem — different fixes
Surfaces the overrun at the halfway point, in numbers a CFO trusts
TCPI gives an honest reality check on whether the budget is recoverable
Works identically across Waterfall and Scrum
⚙️
Live EVM calculator
Enter your four inputs — every metric and the verdict update live. Pre-loaded with Project Atlas.
Units are your own ($k, $, or story-point dollars). All metrics use the standard PMI formulas.
Variances & indices
SV EV − PV——
CV EV − AC——
SPI EV / PV——
CPI EV / AC——
Forecast at completion
EAC BAC / CPI—
ETC EAC − AC—
VAC BAC − EAC——
TCPI (BAC−EV)/(BAC−AC)—
—
🧠
Test yourself
0 / 8
Running a project that is slipping? Book a 30-minute delivery review with Siva: we look at your plan, your numbers and the one thing to fix first.
Companion to Chapter 10 of The Discipline of Delivery by Siva Prasad. Read the chapter to understand why the discipline matters, then use this guide to practise the how.