Earned Value Management vs Burndown: Reporting Progress to Mixed Audiences

The project review runs for 45 minutes. The engineering lead opens with the earned value management question on the table: burndown is steep, velocity held through the last two sprints, nine story points remain, the team expects to finish by Friday. Then the finance partner takes the floor: what is the cost performance index, where is the planned value, how much of the approved budget has been earned. One project. Two lenses. Neither side is wrong. They just cannot talk to each other because the numbers do not translate.

This is not a tool problem. It is a reporting problem. The same project produces two sets of progress indicators, and most PMOs ship them to each audience separately without building the translation layer that would let both audiences understand the project's health at the same time.

The gap has organizational cost. Finance cannot tell whether the velocity story is consistent with the budget story. Engineering has no idea whether their sprint completion rate means the project is in good financial shape. Both can be delivering accurate numbers and still produce a status review where senior stakeholders leave with incompatible interpretations of where the project stands.

TL;DR. Earned value management measures cost and schedule efficiency against a plan. Burndown tracks remaining work over time. You can run both simultaneously and translate between them by using completed work as the common unit. The translation is mechanical once you set it up. The hard part is building a status report that presents both views in a format finance and engineering each trust.

What earned value management actually measures

Earned value management is a performance framework built on three numbers: Planned Value, Earned Value, and Actual Cost.

Planned Value (PV) is how much work you planned to complete by today, expressed in currency. If your project has a $200,000 budget and you planned to be 60 percent done by today, PV is $120,000.

Earned Value (EV) is how much work you have actually completed, in the same currency. If you are only 50 percent done, EV is $100,000.

Actual Cost (AC) is what you have actually spent. If you spent $115,000 to reach that 50 percent, AC is $115,000.

Two performance ratios follow:

• Schedule Performance Index (SPI) = EV / PV. Below 1.0 means behind schedule; above 1.0 means ahead.
• Cost Performance Index (CPI) = EV / AC. Below 1.0 means over budget per unit of work; above 1.0 means under.

In this example: SPI = $100,000 / $120,000 = 0.83 (behind schedule); CPI = $100,000 / $115,000 = 0.87 (over budget per unit of work).

EVM originated in US Department of Defense contracting and became a PMO standard because it gives sponsors one consistent ratio to track across time, rather than a narrative about what the team believes is happening. Finance partners who have worked through large troubled projects default to asking for CPI and SPI because they have watched projects report "on track" in the status narrative while the underlying numbers told a different story.

What a burndown chart actually measures

A burndown chart plots remaining work on the vertical axis against time on the horizontal. The team starts a sprint with a defined number of story points. Each day the chart shows how many remain. An ideal line runs from the total at day zero to zero at the last day. Reality runs above or below that line.

Burndown is useful because it is real-time and actionable within the sprint. If the line is running flat, the team is blocked or the estimates were wrong. If it is falling steeply, the team is moving. Scrum leads and engineering managers read it daily to adjust before the sprint ends.

Burndown does not measure cost. It does not tell you whether the work being completed is costing more or less than planned. It does not show what percentage of the project budget has been consumed. Those are EVM questions.

What burndown does show, if velocity is tracked consistently, is the team's sustainable pace: how many points the team completes per sprint. That number is the foundation of the translation between the two systems. The Agile Alliance's burndown chart reference also flags a key limitation: a declining burndown could reflect completed work or a reduced scope, which is exactly why the EVM view is necessary alongside it.

Why the gap creates earned value management vs burndown reporting problems

The gap between these two metrics produces a specific failure mode: a project can show healthy burndown and negative EVM simultaneously, or vice versa.

A team executing sprint work efficiently but whose scope was underestimated will show good burndown and poor CPI. Burndown says the team is performing well; EVM says the project is over budget. Both are true. Without a translation layer, the finance partner reads the CPI and believes the team is underperforming. The engineering lead reads the burndown and believes the project is on track. Neither is wrong. They are measuring different things.

The decision about whether to add scope, cut features, or adjust the timeline requires a unified view. Separate reporting produces separate narratives that talk past each other in every status review.

The diagram below shows both systems running in parallel on the same project.

The resolution: both measurements are correct. The team is executing at plan velocity. The project is over budget because scope grew mid-project, not because the team underperformed. That is a different conversation, and you can only have it if you run the translation between the two views.

Converting burndown data to earned value management metrics

The translation requires one decision: what unit represents "value" in your EVM calculation. Story points work as a proxy for budget if your team's velocity is stable and consistent.

The conversion:

• EV = (points completed to date / total planned points at baseline) × Budget at Completion (BAC)
• PV = (points planned for completion by today / total planned points at baseline) × BAC
• AC = actual spend to date, from the finance system

Three conditions must hold for this to be reliable:

1. Velocity is consistent enough that a point this sprint represents roughly the same effort as a point last sprint.
2. Total planned points were baselined at project start. Scope additions need to be tracked separately, or the denominator inflates silently and EV looks better than it is.
3. Actual spend is being tracked at a granularity that matches your EVM reporting frequency. Many agile teams have no mechanism to pull AC from the finance system at sprint-by-sprint intervals.

If your team works in hours rather than points, the conversion is more direct. EV equals (hours of work completed against plan / total planned hours) × BAC. Hours are a more defensible proxy for cost than points and remove the need to explain to a finance partner what a planning poker session is.

Bridging the two views in one status report

The status report for a mixed audience presents both views without requiring either audience to read through the other's data.

A format that works: three sections, structured as separate reads.

Section 1: Schedule summary (one sentence, for everyone). "The project will complete the current sprint by June 13 as planned, based on 9 remaining points at current velocity." Both audiences can read this sentence. It translates directly from burndown to EVM scheduling language.

Section 2: Cost performance (finance audience). CPI and SPI as two numbers with a one-line interpretation. "CPI: 0.87. The project is spending $1.15 per $1.00 of work delivered. Root cause: three scope additions in sprints 3 and 4 increased the point total by 15 without a proportional budget increase. These scope items have been added to the baseline."

Section 3: Team execution (engineering audience). Velocity trend, impediments, sprint health. "Velocity held at 10 to 12 points for four consecutive sprints. One impediment in week 3 resolved without schedule impact. Sprint 6 carries no new risk."

The finance partner reads section 2 and understands the cost story without needing to decode story points. The engineering lead reads section 3 and understands the execution story without needing to decode budget ratios. Section 1 is the bridge: the one sentence both can reference together when the conversation opens.

The Status Report Writer tool generates structured output from project data rather than asking PMs to manually reconcile two systems before every report. For teams running this split regularly, having the report scaffold built around the two-audience structure removes the most time-consuming part of the process.

For a broader treatment of what belongs in a status report and why narrative sections consistently mislead sponsors, see the status report writing guide.

When to apply which metric

A few decision rules prevent this from becoming overhead for every project.

Use burndown alone when the project is entirely sprint-based, sponsors only need delivery estimates, and no one requires cost-efficiency reporting. Pure product teams with a single sponsor who asks only "will it be done by Q3" qualify.

Use EVM alone when the project is fully waterfall-structured, all work is planned in a WBS, and detailed actual cost data exists at the task level.

Use both when any of these hold:

• Finance or a PMO requires monthly cost-performance reporting on a project the team is running in sprints
• The project mixes fixed-date waterfall milestones (regulatory submissions, hardware integration, signed contract dates) with sprint-based software delivery
• The project's budget spans multiple teams and the engineering team is one portion of a larger effort with consolidated reporting

The waterfall vs agile guide covers the methodology-level decision in more detail. The EVM-vs-burndown reporting question is downstream of that: once you know what methodology each part of the project is running, the reporting format follows.

Building a reporting cadence that works for both audiences

The diagram below shows a three-tier cadence that separates the engineering, finance, and executive reporting layers without requiring the PM to run a separate meeting for each.

The practical challenge is not the math. It is the cadence mismatch. Sprints run every two weeks. Finance reporting runs monthly. EVM calculations are most useful at monthly or quarterly intervals, when enough data has accumulated to show trend lines worth discussing.

A cadence that resolves this: sprint-close reports for the engineering audience, monthly finance reviews with EVM ratios, and a quarterly dashboard that overlays velocity trend with CPI/SPI trend in the same view. The quarterly dashboard is the artifact that forces both stories into the same frame.

Without a quarterly view, finance and engineering never compare notes. The translation gap persists because there is no natural moment where both sides look at the same picture. The quarterly dashboard creates that moment. Once it exists, the separate monthly reports start to feel like preparation for it rather than disconnected deliverables.

For a PMO building this for the first time: start with CPI and SPI only. Resist adding Estimate at Completion, Variance at Completion, and the full EVM vocabulary at once. Two ratios with a plain interpretation are more likely to be read and trusted than a spreadsheet of acronyms that requires a handout to parse.

The PMO Maturity Assessment includes a scoring section for reporting maturity, which measures how well a PMO's status reports serve different stakeholder audiences. Teams that score low on reporting maturity identify the EVM-vs-burndown translation gap as one of their most consistent friction points.

Run the free Status Report Writer Generate a structured project status report from your schedule data in about five minutes. Built for mixed-audience reporting, so you are not manually reconciling two systems before every review. No signup required. → Open the Status Report Writer