Compare Jira's original estimate with time spent to see effort consumed so far. Add the remaining estimate to see the current forecast. These are different questions: work can remain below its original estimate today while already being forecast to exceed it.
This guide uses a synthetic dataset that you can recalculate. The example describes reporting logic; it is not a claim about results from a customer project or an installed app test.
Choose three fields and one reporting boundary
Use these definitions consistently:
| Field | Meaning in this report |
|---|---|
| Original estimate | The agreed effort baseline, provided it has been preserved |
| Time spent | Effort recorded in worklogs included in the issue totals |
| Remaining estimate | The team's current estimate of effort still needed |
Jira supports time estimates and logged work; available fields and permissions depend on configuration. See Atlassian's time-logging guidance.
Decide whether the report covers an epic, release, sprint, project, or saved issue set. Record the included issue keys and capture time. This prevents a changing filter from quietly changing the question between reports.
Recalculate this five-issue example
All values below are hours. The parent is a container without its own estimate or direct worklogs. Each row represents a distinct leaf issue, counted once.
| Issue | Task | Original | Spent | Remaining | Forecast |
|---|---|---|---|---|---|
| DEMO-101 | Discovery | 20 | 12 | 4 | 16 |
| DEMO-102 | API implementation | 40 | 32 | 16 | 48 |
| DEMO-103 | Interface | 30 | 22 | 12 | 34 |
| DEMO-104 | Documentation | 10 | 8 | 4 | 12 |
| DEMO-105 | Verification | 20 | 12 | 12 | 24 |
| Total | 120 | 86 | 48 | 134 |
Download the example data and expected calculations to check the totals in your own spreadsheet.
Define the calculations before interpreting the signs:
Spent variance = time spent − original estimate Forecast = time spent + remaining estimate Forecast variance = forecast − original estimate Effort consumed (%) = 100 × time spent / original estimate
For this example, spent variance is −34 hours, forecast variance is +14 hours, and effort consumed is 71.7%. A positive variance means more effort than the baseline.
The useful update is: “We have logged 86 hours against 120 planned. We currently expect another 48 hours, giving a 134-hour forecast. API implementation accounts for eight of the fourteen forecast overrun hours.”
That identifies an issue to discuss. It does not establish why the work changed or imply that the people doing it performed poorly.
Keep a missing estimate different from zero
If original estimate is missing, you do not have an agreed baseline for that row. Show variance and percentage as unavailable until the omission is understood. A zero baseline also makes a percentage calculation undefined.
If remaining estimate is missing, do not automatically report it as zero. An issue with 12 logged hours and unknown remaining work has an unknown forecast. Review whether the work is finished or whether the forecast needs updating.
For a portfolio total, show coverage alongside the result: for example, “Five of six issues have a baseline; the unestimated issue has four logged hours.” Do not hide the sixth issue merely to produce a complete-looking ratio.
Avoid double counting parents and children
A parent can hold its own effort, represent child effort, or contain an aggregate value from a reporting tool. Those are not interchangeable.
Write a rule appropriate to your team's data. For example: “Sum direct values from the five listed leaf issues; exclude the parent container.” If the parent also contains genuine direct work, account for that separately. Do not add a parent aggregate to the same child values that produced it.
When totals disagree, compare issue keys and hierarchy rules before comparing formulas. A correct sum of the wrong issue set is still the wrong report.
Check the cases that a complete-looking total can hide
The first dataset has complete inputs. A second, fictional boundary-case dataset tests missing estimates, a zero baseline and a parent aggregate. Blank cells mean unknown values.
| Direct issue | Original / spent / remaining hours | Expected result |
|---|---|---|
| CHECK-1 | 12 / 8 / 6 | Forecast 14 hours; forecast variance +2 hours |
| CHECK-2 | Unknown / 4 / 3 | Forecast 7 hours; baseline variance unavailable |
| CHECK-3 | 0 / 2 / 0 | Forecast 2 hours; effort-consumed percentage undefined |
| CHECK-4 | 10 / 3 / unknown | Spent variance −7 hours; forecast unavailable |
The file also contains an explicitly labeled parent aggregate showing 17 spent hours. The four direct rows already sum to 17 hours; including that aggregate would produce 34. The example's accounting rule excludes it. A parent with separate direct work would need a different record and an explicit inclusion rule.
Use the expected results to check your spreadsheet. Our local reference calculation verifies every row, preserves unknown values and leaves undefined percentages blank. It does not certify a particular Jira report or app.
The resulting review is more informative than one total: “17 hours are logged; four belong to an issue without a baseline, and one issue's remaining work is unknown.” For period-specific totals, continue with the dated worklog reconciliation example.
Preserve the baseline and the reporting period
An editable original-estimate field is not automatically an immutable historical baseline. If you need to explain changes since approval, retain the approved issue set and values in a dated export or another controlled record.
Likewise, an issue's lifetime time-spent total is not the time logged during a particular month. Monthly effort needs worklog dates and a defined timezone. Reusing lifetime totals in a monthly table can assign old effort to the wrong period.
See the sprint scope guide when new or removed work changes the boundary. Use the remaining-estimate guide when the issue set stays stable but the forecast changes. For repeated snapshots across both conditions, use the four-sprint Jira continuous-forecasting example.
Turn the report into a decision
Review the largest positive forecast variances with the people doing the work. Ask whether the cause is new scope, a changed approach, a correction to an old estimate, or a reporting omission. Record the explanation alongside the number.
If the report is about money, introduce an explicit costing method. Hours are not currency, story points are not hours, and a blended rate is an assumption that should be visible. Do not label an effort variance as a financial loss without the additional calculation.
TimePillar is one option to evaluate for bringing related Jira time fields into a roll-up. Use a small known dataset like this one to check any reporting workflow before sharing larger totals.
Common questions
Can a report be under estimate and still at risk?
Yes. Here, 86 logged hours are below the 120-hour baseline, but 48 hours remaining produce a 134-hour forecast. The risk appears before actual effort crosses the baseline.
Should I average individual percentages?
For an aggregate effort-consumed ratio, divide total spent by total baseline for the same eligible rows. A simple average gives a one-hour issue the same weight as a hundred-hour issue.
Does an overrun prove the original estimate was bad?
No. Inspect scope and history first. The report shows a difference; the team supplies the explanation and decides whether to revise the plan, reduce scope, or accept the additional effort.
Next steps
- Reviewing an active sprint? Use the Jira sprint budget-overrun guide to turn the fields into an early-warning check.
- Need a rollup for managers? Review TimePillar for Jira against one real project or epic.