Earned Value Management

The Earned Value panel sits near the bottom of a project's Analytics page, grouped with the Budget card. If you've never used Earned Value Management (EVM) before, this page teaches the whole concept from scratch - what each number means, how orboto computes it from your tickets and time entries, and how to read a healthy picture from an unhealthy one.

The idea, in one sentence

EVM answers one question a plain burndown chart can't: "for the money and time we've spent so far, did we get the progress we should have?" A project can look fine on a burndown (tickets are closing) while quietly running over budget, or look fine on budget (spend is on track) while quietly falling behind schedule. EVM catches both at once by comparing three numbers.

A worked example

Imagine milestone Sprint 7 in project ACME, budgeted at 100 hours (its BAC, explained below), running Monday through the Friday of the following week - 10 working days. It contains 10 tickets, each estimated at 10 hours (100 hours of estimated work in total, matching the budget).

Today is the 5th working day - exactly the halfway point. So far:

• 4 tickets have been closed (40 hours of estimated work delivered).
• The team has logged 44 hours of actual time.

Here is what EVM reports, and what each figure means.

The three curves

Notice EV is not "how many hours got logged" and it is not "40% of the way through the checklist" either - it is specifically the budget share of the work that's actually closed, weighted by each ticket's estimate. A ticket that's 90% done but still open contributes nothing under orboto's default crediting rule (more on that below).

Reading the gap: SPI and CPI

Two ratios turn those three numbers into a straight "ahead or behind" read:

• Schedule Performance Index (SPI) = EV / PV -> 40 / 50 = 0.8. SPI of 1.0 is exactly on schedule. Above 1 means ahead. Below 1 means behind, and by how much: an SPI of 0.8 means the team is earning value at 80% of the planned pace - for every 5 hours of schedule that passed, only 4 hours of value came out the other end.
• Cost Performance Index (CPI) = EV / AC -> 40 / 44 ≈ 0.91. CPI of 1.0 is exactly on budget. Above 1 means you're getting more value than you're paying for (under budget). Below 1 means the reverse: a CPI of 0.91 means every hour spent is buying about 0.91 hours of earned value - if that efficiency holds for the rest of the work, the milestone will end up costing roughly 1 / 0.91 ≈ 10% more than planned.

In this example: SPI 0.8 and CPI 0.91 together describe a milestone that is both a bit behind schedule and running a bit over budget - the classic pattern EVM exists to catch early, while there's still runway to react.

Forecasting the ending: EAC and variance

• Estimate at Completion (EAC) = BAC / CPI -> 100 / 0.91 ≈ 110h. If the current cost-efficiency holds for the rest of the work, this is the projected final cost.
• Estimate to Complete (ETC) = EAC - AC -> 110 - 44 = 66h. How much more spend is expected before the milestone is done.
• Variance at Completion (VAC) = BAC - EAC -> 100 - 110 = -10h. A negative VAC is a projected overrun (spending more than budgeted); a positive VAC is a projected underrun.
• To-Complete Performance Index (TCPI) = (BAC - EV) / (BAC - AC) -> (100 - 40) / (100 - 44) = 60 / 56 ≈ 1.07. This is the efficiency the remaining work needs to hit to still land on the original budget. A TCPI above 1 means the team needs to get more efficient than it's been so far to recover - not just keep going. A TCPI far above 1 (say, well past 1.1-1.2) is usually a sign that the original budget itself needs revisiting rather than squeezed harder.

The tiles and chart on the page

The panel shows SPI, CPI, SV (schedule variance, EV - PV), CV (cost variance, EV - AC), EAC and VAC as tiles, colour-coded green when the number is on the healthy side (SPI/CPI at or above 1, SV/CV/VAC at or above 0) and red otherwise, plus a line chart of the PV / EV / AC curves across the milestone's window. PV is drawn all the way to the milestone's end date as the baseline reference; EV and AC only accrue up to today - they are never projected into the future, only PV is.

Controls

• Hours / Money toggle - switches the whole panel's unit. Money needs budget:view; without it, only Hours is offered.

• 0-100 / 50-50 toggle (labelled with a hint on hover) - how an in-progress ticket earns credit before it closes:

  • 0-100 (default): a ticket earns nothing until it closes, then all of its estimate-weighted share at once.
  • 50-50: a ticket earns half its share the moment work first starts on it, and the other half on close.

  Important nuance: "started" here means the first time entry was logged on the ticket - not the moment its status moved to "In Progress." A ticket sitting in an in-progress column with zero logged time has not "started" under this rule yet.

• Milestone scope - there is no separate milestone picker on this panel; it follows the same dropdown that lives inside the Burndown card further up the page. Leaving it on "All milestones" scopes EVM to the whole project instead of one milestone (see below).

Exactly what orboto feeds into the calculation

• BAC (Budget at Completion) = the selected milestone's budget (hours or money), falling back to the project's budget if the milestone has none set.
• The window = the milestone's start and end dates. With no milestone selected (project scope), the window is the span across every milestone in the project - the earliest milestone start to the latest milestone end - not the project's own creation date.
• PV ramps over working days, not raw calendar days: weekends, public holidays, and company closures (the same blocked-days calendar used by Time tracking and Capacity) are skipped, so a five-day sprint with one holiday in it ramps PV over four working days, not five calendar ones.
• EV = BAC x (sum of estimates of tickets counted as earned) / (sum of estimates of every ticket in scope). Tickets with no estimate contribute zero weight either way - they don't inflate the total and they can never earn anything themselves. If every ticket in scope is unestimated, there is nothing to divide by and EV stays 0 regardless of how many tickets close.
• AC (hours mode) = the sum of logged time entries up to today. AC (money mode) = those same hours priced per contributor: their own hourly rate if set, otherwise the project's hourly rate. Unlike the Budget card, EVM's money mode does not fall back further to the customer's default rate - a contributor with neither a personal nor a project rate contributes 0 cost here even if the Budget card would have priced them via the customer.
• As-of date is always today in the UI. The underlying API accepts a historical asOf date for scripted/agent use, but the panel itself has no date picker for it.
• Only tickets you're allowed to see count - the same private-ticket and guest-visibility rules as the rest of the project apply.

Reading a healthy vs unhealthy picture

• Healthy: the EV line tracks close to the PV line (on schedule), and the AC line sits at or below EV (on or under budget). SPI and CPI both sit at or above 1.
• Behind schedule, on budget: EV visibly below PV, but AC also below or near EV. SPI under 1, CPI near or above 1 - slow, but not burning cash to compensate.
• On schedule, over budget: EV tracks PV, but AC rides well above EV. SPI near 1, CPI under 1 - hitting dates by spending more than planned to get there.
• Both behind and over budget (the worked example above): EV lags PV and AC rides above EV. This is the pattern worth raising early - it rarely self-corrects without a scope, schedule, or budget change.
• Common misreading: EV is not "percent of tickets touched" or "percent of time spent." A ticket that's 90% finished but still open earns 0% under the default 0-100 rule (or 50% under 50-50, once time was first logged on it) - never a smooth 90%. orboto does not offer a %-complete credit rule today; if your team routinely under-reports progress because of this, switching to 50-50 gives partial credit earlier without needing one.

Requirements & empty states

EVM needs a baseline before it can compute anything, so the panel tells you exactly what's missing rather than showing a blank chart with no explanation:

• "Set start and end dates on the milestone..." - the milestone (or, in project scope, its milestones collectively) has no start/end window. Fix: set the milestone's start and end date in its details.
• "Set a budget on this milestone (or the project)..." - neither the milestone nor the project has a budget configured in hours or money. Fix: set one in Project settings, or the milestone's own budget field.

Troubleshooting

• The panel shows an empty state instead of a chart. Read the message - it's always one of the two requirements above, never a generic failure.
• EV never moves even though tickets are closing. Check whether the closing tickets actually have estimates set. An unestimated ticket earns nothing when it closes, and if the whole scope is unestimated, EV is permanently 0. Add estimates and it will start moving.
• Money mode is missing (only Hours is offered). You don't have budget:view on this project. Ask a project admin.
• AC in money mode looks lower than I expected. EVM's money mode only falls back from a contributor's own rate to the project rate, not the customer's default rate - see Exactly what orboto feeds into the calculation above. Set a project hourly rate as a safety net if you rely on the customer-level fallback elsewhere.
• SPI or CPI shows a dash instead of a number. They're undefined when the denominator is exactly 0 - SPI needs PV greater than 0 (normal right at the very start of a milestone, before any working days have elapsed) and CPI needs AC greater than 0 (before any time has been logged yet). This resolves itself once the milestone is underway.
• Switching between 0-100 and 50-50 changes EV a lot. Expected - 50-50 gives partial credit for started-but-not-closed work, so it reports a higher EV (and usually a healthier SPI) than 0-100 for the same actual progress. Pick whichever credit rule matches how your team actually wants "in progress" work represented, and stay consistent with it over time so comparisons across periods stay meaningful.