Effort variance calculator
A task planned at 40 hours that took 48 shows an 8-hour overrun, or +20%, and is labeled as one; finishing in fewer hours than planned shows as a negative underrun. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Planned hours
- 40
- Actual hours
- 48
- Variance hours
- 8
- Abs variance hours
- 8
- Variance percent
- 20
- Abs variance percent
- 20
Effort variance is the gap between the hours a project, sprint, or work package was supposed to consume and the hours that were actually logged. Delivery managers, PMO analysts, scrum masters, and engineering leads track that gap so they can spot overruns before a forecast slips, explain underruns that free capacity, and keep a defensible audit trail of planned versus actual labor. This effort variance calculator accepts planned hours and actual hours, subtracts the plan from the actuals to produce a signed hour variance, takes the absolute value of that difference, divides the signed variance by planned hours to produce a percentage, and labels the result as an overrun, an underrun, or on plan.
What effort variance means and how the formulas work
In project performance tracking, effort variance is the difference between the labor hours that were budgeted or estimated and the labor hours that were actually consumed. The signed hour variance is actual hours minus planned hours: a positive result is an overrun (more time than planned), a negative result is an underrun (less time than planned), and zero means the work landed on plan. The absolute hour variance is the magnitude of that gap without a sign, which is useful when a dashboard only needs the size of the miss.
Percentage variance divides the signed hour variance by planned hours and multiplies by one hundred, so an actual of forty-eight against a plan of forty is a plus twenty percent overrun, and an actual of seventy-two against a plan of eighty is a minus ten percent underrun. The absolute percentage is the magnitude of that rate. Fractional hours are allowed so you can send 6.5 or 40.25 from a timesheet export.
Where an effort variance calculator earns its keep
Program managers and PMO analysts use an effort variance calculator at weekly status to turn timesheet actuals and baseline estimates into a signed variance, an absolute miss, and a percentage they can drop into a steering-committee slide without debating spreadsheet signs. Scrum masters compare planned sprint hours to logged hours after the review so they can explain an overrun that ate slack or an underrun that frees capacity for the next increment.
Professional-services firms and agencies compare sold hours to delivered hours on a work order so billing and delivery stay honest before an invoice goes out. Resource managers watch percentage variance across projects to find chronic overruns that hide under-estimation, not just one noisy week. Training courses and LMS plugins need a deterministic oracle that rejects a zero plan instead of silently emitting NaN that a buggy grader might treat as success.
Failed validation does not consume balance. Keep requests small, pin the rounded variance fields in tests, and you get reproducible planned-versus-actual hour reports for status packs, edge workers, and CI checks without standing up a full project-portfolio stack of your own.
What you can do with it
Weekly project status pack
Turn baseline planned hours and timesheet actuals into signed, absolute, and percent variance so a steering slide shows overrun or underrun without a spreadsheet-sign debate.
Sprint review hour reconciliation
Compare the hours the team planned for a sprint against hours logged after the review and label the gap as overrun, underrun, or on plan.
Sold versus delivered hours
Professional-services and agency teams compare sold effort to delivered effort on a work order before an invoice goes out.
FAQ
How is effort variance calculated?
Positive values are overruns; negative values are underruns.
What is the difference between absolute and signed variance?
Signed variance keeps the direction of the miss (over versus under). Absolute variance is the magnitude without a sign, useful when a dashboard only needs how large the gap is. Both hour and percent forms are returned.
Why must planned hours be greater than zero?
Percentage variance divides by the plan. Actual hours may be zero (a full underrun against a positive plan).
What does a negative effort variance mean?
It is an underrun: the work took fewer hours than planned, so the variance and the percentage come out below zero. Logging no hours at all against a plan is a 100% underrun.
What is the effort ratio?
Actual hours divided by planned hours. A ratio of 1 means on plan, above 1 means more hours than budgeted, and below 1 fewer. 48 hours against 40 gives 1.2.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/biz/effort-variance \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"planned_hours":40,"actual_hours":48}'const res = await fetch("https://api.kit.forhosting.com/biz/effort-variance", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"planned_hours": 40,
"actual_hours": 48
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/biz/effort-variance",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"planned_hours": 40,
"actual_hours": 48
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/biz/effort-variance", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"planned_hours":40,"actual_hours":48}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"planned_hours":40,"actual_hours":48}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/biz/effort-variance", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"planned_hours": 40,
"actual_hours": 48
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "biz.effort_variance",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Zero planned hours makes the percentage undefined and fails with invalid_input instead of returning infinity. Invalid inputs fail with invalid_input and are not billed.
What effort variance means and how the formulas work
The effort ratio is actual divided by planned: one means on plan, values above one mean the team spent more hours than budgeted, and values below one mean they spent fewer.
Input contract, response shape, and error behaviour
Zero actual hours is valid and means no labor was logged against the plan, which produces a one-hundred percent underrun. Zero planned hours is not valid: percentage variance is undefined when the denominator is zero, so the task fails instead of returning Infinity or NaN that a buggy report might treat as success. Keep units consistent across a reporting series: if you model planned hours as person-hours, send actuals in the same unit. POST a JSON body with two required finite numbers: planned_hours (the budgeted or estimated effort, strictly greater than zero) and actual_hours (the hours logged, greater than or equal to zero). Missing fields, empty strings, non-finite values, negative actual hours, and non-positive planned hours fail with invalid_input naming the field. On success the body echoes both drivers and returns variance_hours (actual minus planned), abs_variance_hours (the absolute hour gap), variance_percent (signed percent of plan), abs_variance_percent (the absolute percent gap), ratio (actual divided by planned), status as overrun, underrun, or on_plan, and a formula string restating the identities. When actual hours are greater than zero the body also includes efficiency_percent, which is planned divided by actual times one hundred (one hundred means the work used exactly the planned hours; above one hundred means it used fewer). Pair the numeric result with your own cost rates, remaining estimates, and earned-value indices outside this endpoint; the calculator compares hours only and does not emit timesheets, invoices, or Gantt bars.
Technical questions
What do overrun, underrun, and on_plan mean?
Overrun means actual hours exceeded the plan (positive variance). Underrun means actual hours were below the plan (negative variance). On plan means the two hour values match after rounding.
What does the effort variance calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.