The useful Jira warning is often already in the issue list. It just does not look like a budget report yet.
A project manager is preparing for a status meeting. One issue was estimated at 20 hours and already has 22 hours logged. Another is estimated at 40 hours, has 32 hours logged, and still has 16 hours remaining. A third has logged time but no original estimate at all.
The team can explain each one. The stakeholder will still ask the same question:
"Are we over the estimate anywhere, and which issues are driving it?"
That is where Jira work ratio earns its place. It is a fast issue-level warning signal for work that has consumed most or all of its original estimate.
But it is not the whole budget answer. Work ratio can help you find trouble before the meeting. It cannot, by itself, produce a reliable epic, parent, sprint, project, or stakeholder rollup.
What Jira Work Ratio Actually Measures
Atlassian's JQL fields reference defines workRatio as:
workRatio = timeSpent / originalEstimate x 100
The same page documents originalEstimate, timeSpent, and remainingEstimate as JQL fields, and shows workRatio > 75 as an example for finding work where more than 75% of the original estimate has been spent.
That makes work ratio useful for a very specific question:
"Which issues have already used most or all of their original estimate?"
If an issue has an original estimate of 20 hours and 22 hours logged, its work ratio is 110%. That is a clean issue-level warning. The team has already logged more than the original estimate.
If an issue has an original estimate of 40 hours and 32 hours logged, its work ratio is 80%. That is not an overrun yet. It is a warning zone, especially if the assignee still expects meaningful work to remain.
The phrase Jira time spent original estimate sounds like a search query because that is exactly what teams are trying to compare. Work ratio gives you that comparison at issue level.
Save These Work-Ratio JQL Filters
Start with the filter that finds work already over the original estimate:
workRatio > 100
Use it before status meetings, sprint reviews, or budget check-ins. It gives you the issues where the Jira over estimate signal is already visible.
Then save a warning-zone filter:
workRatio >= 80 AND workRatio < 100
The threshold is a policy choice. Some teams use 75%. Some use 90%. The point is not the exact number. The point is that project managers should see issues nearing the estimate before the ratio crosses 100.
Add a missing-baseline filter:
originalEstimate IS EMPTY AND timeSpent > 0
This catches issues with logged time but no original estimate. Those issues may be valid support work, production incidents, or scope added after planning. They still need a reporting rule, because they cannot produce a meaningful work-ratio signal without a baseline.
Add a no-worklog filter:
originalEstimate IS NOT EMPTY AND timeSpent IS EMPTY
That finds estimated issues with no logged time. Early in a sprint, this may be normal. Late in delivery, it can mean the team is not logging work where the report expects it.
Finally, use remaining estimate to catch stale forecast data:
remainingEstimate > 0 AND statusCategory = Done
Atlassian's time tracking documentation says time tracking appears on a work item and shows logged time and remaining time. If done issues still carry remaining estimate, your forecast can look worse than the team actually believes.
The Signal Work Ratio Misses
Work ratio uses timeSpent. It does not include remainingEstimate.
That is why a ratio below 100 can still hide a budget problem.
Example:
- Original estimate: 40h
- Time spent: 32h
- Remaining estimate: 16h
- Work ratio: 80%
- Forecast total: 48h
- Forecast variance: +8h
The issue is not over the original estimate yet. But the team is currently forecasting 48 hours against a 40-hour baseline.
For budget conversations, track two signals:
- Spent signal:
time spent / original estimate x 100 - Forecast signal:
time spent + remaining estimate - original estimate
Work ratio tells you whether logged work has already consumed the estimate. Forecast variance tells you whether the work is likely to finish over the estimate if the remaining estimate is realistic.
If the status report only uses work ratio, you may catch overruns after they have already happened. If it also checks remaining estimate, the project manager can say:
"This issue is only at 80% of original estimate spent, but the current forecast is 8 hours over. We should talk about scope or re-estimation now."
That is the budget conversation you want before the meeting, not after it.
Admin Checks Before You Trust the Filters
The filters only help if the Jira time-tracking setup is usable.
Atlassian's time tracking administration documentation says Jira Cloud time tracking is enabled by default, but users need the Work On Work Items permission to log work. It also says admins can control whether the Time tracking field is shown through company-managed field configurations or team-managed work-type fields.
Before treating work ratio as a reporting signal, check:
- Can the team see and edit the Time tracking field where they work?
- Do the right users have permission to log work?
- Is original estimate entered before work starts, or added after the fact?
- Are remaining estimates updated during delivery?
- Are time units understood consistently: hours, days, weeks, and default unit?
- Does the person preparing the report have permission to see the relevant worklogs?
If those answers are weak, work ratio will surface symptoms. It will not fix the reporting process.
Where The Ratio Stops Being A Rollup
The most common mistake is treating issue-level work ratio as if it were a parent, epic, sprint, or project budget rollup.
It is not.
Epic and parent rollups
Atlassian's JQL fields reference documents the parent field for finding child work items:
parent = ABC-123 AND workRatio > 100
That is useful. It can show child issues under a parent that are already over estimate.
It still does not answer:
"Is this epic over budget?"
The filter returns issue rows. It does not decide which estimates count, how subtasks are included, or whether parent estimates and child estimates should be added together.
That distinction matters. A parent issue may have its own original estimate while child issues also carry estimates. If a report sums both levels, the baseline can be doubled. If the parent has no estimate and the children carry the real work, looking only at the parent can make the budget look empty.
Write the estimate rule before you roll anything up:
- Parent estimate is the baseline; child estimates are delivery detail.
- Lowest-level estimates are the baseline; parent values are rollups.
- If both parent and child estimates exist, one level wins.
- Scope added after approval is separated from the original baseline.
Work ratio helps identify the child issues to inspect. It does not create the rollup rule for you.
Sprint rollups
Sprint filters are useful too:
sprint in openSprints() AND workRatio > 100
That can help a scrum master find active-sprint issues already over estimate.
But sprint reporting has its own boundaries. Atlassian's sprint report documentation says estimates on subtasks are not included in the sprint report, the report is board-specific, and it only includes work items matching the board's saved filter.
So the sprint report may be correct for the Scrum board and still incomplete for the budget question. If developers log time on subtasks, if the epic spans boards, or if moved work still matters to the stakeholder, a sprint-level work-ratio filter is only a starting point.
Stakeholder and project rollups
Stakeholders rarely ask for a raw ratio. They ask for the story behind the number:
- What was the approved estimate?
- How much has been logged?
- What remains?
- Are we over or under?
- Which issues explain the movement?
JQL can identify the rows. Atlassian documents search exports to CSV, Google Sheets, Microsoft Excel, Word, XML, and form data, so exporting remains a supported path for audits and one-off analysis.
The problem starts when the same export becomes the weekly calculation engine. If every status meeting starts with a spreadsheet rebuild, the work-ratio signal is too far from the rollup explanation.
A Meeting-Ready Workflow
Use work ratio as the first pass, then build the explanation.
Start with scope:
- one parent issue
- one epic
- one sprint
- one project or space
- one release
- one saved filter
- one client-facing workstream
Then run three filters for that scope:
- Over estimate:
workRatio > 100 - Near estimate:
workRatio >= 80 AND workRatio < 100 - Missing baseline:
originalEstimate IS EMPTY AND timeSpent > 0
Then check remaining estimate:
- Is any done work still carrying remaining estimate?
- Are high work-ratio issues also showing large remaining estimate?
- Did the team update remaining estimate after the last meaningful worklog?
Then summarize the drivers:
"Five issues are over original estimate. Two are small and already done. The real variance is from API authentication and QA regression work. The epic has 86 hours logged against a 120-hour baseline, but the current remaining estimate pushes the forecast to 134 hours."
That answer does more than quote work ratio. It explains the Jira budget variance in terms stakeholders can act on.
When Native Jira Is Enough
Do not add tooling before checking whether the native workflow already solves the problem.
Work-ratio filters may be enough when:
- The team estimates and logs time at the same issue level.
- Parent and child estimate rules are consistent.
- Stakeholders only need a list of risky issues, not an audited rollup.
- Sprint questions stay inside one board filter.
- Remaining estimates are maintained well enough for forecast checks.
- Exports are occasional, not a recurring reporting process.
Jira Plans can also help in planning contexts. Atlassian documents that Plans roll up estimates in Jira Cloud Premium and Enterprise, and that rolled-up estimates can change as time is logged to child work items.
That is useful planning signal. It still may not be the exact operational report a project manager needs for a client update, sprint review, or budget meeting.
What to Verify Before Adding a Rollup App
If work-ratio filters keep turning into manual rollups, evaluate the reporting gap directly.
Ask:
- Does the app use native Jira time-tracking fields?
- Does it show original estimate, time spent, remaining estimate, and variance together?
- Does it support the hierarchy you report on: subtasks, stories, epics, parents, projects, releases, or saved filters?
- How does it avoid double counting when parent and child estimates both exist?
- Can managers inspect the child issues behind a total?
- Does it respect Jira permissions and worklog visibility?
- What Jira products and hosting models are publicly supported?
- What permissions or scopes does it request?
- Are privacy, security, support, and pricing information publicly clear?
- Can it export a clean summary when stakeholders need a file?
Trial it against one real report. Do not evaluate it only against a demo project with perfect estimates.
Where TimePillar Fits
TimePillar is Backlog Bridge's product for teams that need Jira time rollups closer to the issue view.
The use case is narrow: a project manager opens a parent, epic, or project context and needs estimate, logged time, remaining work, variance, and child-issue visibility without rebuilding the same spreadsheet before every meeting.
That complements Jira work ratio. Work ratio is the warning light. A rollup view turns warnings into an explainable status-meeting answer.
See how Jira time rollups in TimePillar help teams bring estimate, logged time, variance, and child-issue visibility closer to delivery reporting.
Use The Signal, Then Explain The Number
Jira work ratio is useful because it is narrow. It shows whether logged time has consumed the original estimate on an issue.
Use it to find problems early:
- issues already over estimate
- issues close to the estimate
- issues with logged time but no baseline
- issues where remaining estimate changes the forecast
Then slow down before turning the ratio into a stakeholder number.
Define the scope. Decide which estimate level counts. Check remaining estimate. Separate issue-level warnings from epic, parent, sprint, and project rollups.
The goal is not to make Jira work ratio do every reporting job. The goal is to use it as an early warning, then explain the budget variance before the meeting starts.