The 5 Jira Time Reports Every Project Manager Asks For (And Where Native Jira Stops)

The steering update is in twenty minutes. The project manager has Jira open, a saved filter, and the same five Jira time reports to rebuild before anyone asks a follow-up question.

Those reports are rarely exotic. They repeat every sprint, every client check-in, and every budget review:

1. How many hours did we burn this sprint?
2. What did we estimate vs log on this epic or project?
3. Who logged how much?
4. Which work is over budget?
5. What hours were logged in this period?

Native Jira can answer pieces of each question. The friction appears when the answer needs a total, a hierarchy rollup, or a date window — and Jira hands back rows instead of a meeting-ready number.

"Just give me the hours story for this epic — estimated, logged, and where we are over."

That question is why this catalog exists.

The Five Reports at a Glance

Before diving into each report, match the question to the job:

The rows are a map, not a verdict. Your instance, board filters, and estimation rules will change which native path is "good enough."

Lock Scope Before You Trust Any Number

Every report below needs the same upfront rule. Write it down before you export, screenshot, or paste into Confluence:

• Which project, epic, sprint, or saved filter counts?
• Are subtasks included?
• Are done issues included?
• Does the board filter match the stakeholder scope?
• Are parent and child estimates both counted, or only one level?

Atlassian's sprint report documentation says estimates on subtasks are not included and the report is board-specific. The same scope problem appears with parent filters, epic links, and mixed estimation levels.

Without a written rule, sprint reports, JQL filters, dashboard gadgets, and spreadsheet exports will disagree — and the project manager becomes the reconciliation layer.

Report 1: How Many Hours Did We Burn This Sprint?

The question: What did the team log during this sprint, and how does it compare to what we committed?

Native Jira path

• Sprint report on the Scrum board for committed vs completed work and sprint shape
• Sprint burndown or Sprint Health gadgets on a Jira dashboard
• Advanced search with sprint JQL and time columns, for example:

sprint in openSprints() AND timeSpent > 0

Where native Jira stops

• The sprint report explains sprint flow. It is not always a full Jira time report for logged hours by epic, assignee, or client slice.
• Estimates on subtasks are not included in the sprint report. Teams that log on subtasks may see a clean sprint story and an incomplete hours story.
• JQL returns issue rows with per-issue timeSpent. Search does not sum sprint hours in a footer total.

What to try next

If the meeting needs a sprint total with assignee or epic breakdown, export the sprint-scoped filter and aggregate in Sheets or Excel. If the team already uses a timesheet app, pull the period view there instead of rebuilding JQL every week.

For subtask-heavy delivery, see Jira subtasks and sprint reporting gap. For dashboard visibility vs hour explanation, see Why your Jira dashboard still cannot explain where the hours went.

Report 2: What Did We Estimate vs Log on This Epic or Project?

The question: For this epic, feature, or project, what was the baseline, what is logged, what remains, and which child issues explain the variance?

This is the report behind most recurring Jira project manager reports. It is also the one native Jira gets closest to without fully closing.

Native Jira path

• Epic report and epic burndown on the board (report types)
• Issue-level time tracking showing logged and remaining time (log time on a work item)
• Jira Plans estimate rollups on Premium and Enterprise (how Plans roll up estimates)
• Search with original estimate, time spent, and remaining estimate columns, then export to CSV or Excel

Where native Jira stops

• Time fields live on work items. They do not automatically roll up to the epic or project container the stakeholder names in the meeting.
• Plans answers portfolio and planning questions. Operational client updates often need named child breakdowns at delivery scope — see Jira Plans rollups vs project reporting.
• Dashboard gadgets show status well but often miss explainable hour rollups with variance and child drivers.
• Large hierarchies need cautious scoping. Existing site articles note Atlassian documentation that work items with more than 100 child work items cannot include those children in time tracking in some native contexts.

What to try next

If the same epic or project rollup is rebuilt every sprint, move the calculation closer to Jira: a rollup panel on the parent issue, or a documented export only when the file must leave Jira.

That is the workflow behind Why Jira project managers still live in Excel. Export should become the output, not the engine.

Report 3: Who Logged How Much?

The question: Which assignees logged time this sprint, week, or billing period — and how many hours each?

Native Jira path

• Advanced search filtered by assignee, sprint, or project with timeSpent visible in columns
• Two Dimensional Filter Statistics or filter-table dashboard gadgets for assignee vs status views
• Worklog history on individual issues, opened issue by issue

Where native Jira stops

• JQL timeSpent reflects total logged time on an issue, not hours logged within a specific date range.
• Native search does not produce a standard worklog-by-user-and-date report across a project without export math or a timesheet product.
• Permissions matter. Totals that look correct for admins may hide child worklogs for project managers with narrower access.

What to try next

Treat this as a category decision:

• Occasional assignee review: export a scoped issue set and pivot by assignee.
• Recurring period governance: evaluate timesheet or billing-category Marketplace apps.
• Hierarchy totals by assignee under an epic: you may still need Report 2 rollup rules first; assignee slices do not fix missing parent totals.

See TimePillar vs Jira time tracking Marketplace apps for how rollup, timesheet, and billing categories differ — this article does not rank them.

Report 4: Which Work Is Over Budget?

The question: Where have we exceeded the original estimate, and which issues need attention before the stakeholder update?

Native Jira path

• JQL workRatio when time tracking is enabled. Atlassian defines it as timeSpent / originalEstimate x 100 in the JQL fields reference
• Over-budget filter:

workRatio > 100

• Warning-zone triage:

workRatio >= 80 AND workRatio < 100

• Issue time tracking panel comparing original estimate with logged time

Where native Jira stops

• Work ratio is issue-level. It does not roll up to epic or project variance.
• Issues with logged time but no original estimate need a separate rule. They will not produce a meaningful work-ratio comparison without a baseline.
• Work ratio ignores remaining estimate. A ratio below 100 can still hide forecast risk when remaining estimate stays high.

What to try next

Use saved over-budget filters for triage before the meeting. When the stakeholder question is "are we over on this epic or client feature?" move to Report 2 rollup paths rather than summing issue ratios by hand.

See Jira work ratio over budget, original estimate vs time spent in Jira, and Can JQL show time spent in Jira? for related filters and aggregation limits.

Report 5: What Hours Were Logged in This Period?

The question: What worklogs fall in this invoice window, client month, or review period?

Native Jira path

• Issue search scoped to work active in the period (indirect)
• Per-issue worklog history on each work item
• Export when the issue set is already defined and the meeting needs a file

Where native Jira stops

• Native JQL does not filter by worklog date the way finance and delivery period reports usually require. Issue-level timeSpent totals mix logging from multiple periods unless scope is tightly controlled.
• Approval workflows, billable flags, cost rates, and locked periods typically live in timesheet or billing apps — not in native issue search.
• Rollup tools that answer Report 2 hierarchy questions do not, by themselves, replace period timesheet governance.

What to try next

• Rare audit: manual worklog export from a tightly scoped issue list.
• Recurring invoice or payroll period: evaluate timesheet-category apps and verify data residency on Marketplace Privacy & Security tabs.
• Delivery variance on a fixed body of work: combine period scoping with Report 2 rollup rules so you do not compare unrelated logging history.

Admin Checks That Affect Every Report

Time-related reporting only works when the underlying setup is usable.

Atlassian's time tracking administration documentation says Jira Cloud time tracking is enabled by default, users need the Work On Work Items permission to log work, and admins control whether the Time tracking field is shown.

Before trusting any of the five reports, check:

• Can the team see and edit the Time tracking field where they work?
• Do the right users have permission to log work?
• Are original estimates entered before work starts?
• Are remaining estimates updated during delivery?
• Can the person running the filter see the relevant worklogs?
• Are time units configured consistently across projects?

If those answers are weak, every report will surface symptoms. None of them will fix the process.

When Exports Are Enough — and When They Become a Trap

Exporting search results to CSV, Excel, or Google Sheets is a supported native path. Use it intentionally.

Exports are enough when:

• The report is occasional, not weekly
• One person owns the formulas
• Stakeholders accept a file rather than a live view
• The JQL scope already matches the reporting scope

Exports become a trap when every status meeting rebuilds the same pivot. That is the manual loop this catalog is trying to shorten — not eliminate for ad hoc analysis.

What to Verify Before Adding a Reporting App

Match the app category to the report job:

• Report 2 or 4 gaps: rollup tools that read native Jira time fields, show child breakdown, and export summaries
• Report 3 or 5 gaps: timesheet, billing, or capture apps with period and approval workflows
• Visibility gaps: dashboard gadgets — distinguish charts from calculation

Ask before installing:

• Does the app use native Jira time-tracking fields or a separate time system?
• Which hierarchy levels does it support: subtask, story, epic, project, filter?
• Can managers inspect the child issues behind a total?
• What Jira products and hosting models does the vendor publicly support?
• What permissions or scopes does the app request?
• Are privacy, security, support, and pricing details publicly clear?

Trial against one real recurring report. Do not evaluate against a demo project with perfect estimates.

Where TimePillar Fits

TimePillar is Backlog Bridge's product for teams whose recurring pain matches Reports 2 and 4: hierarchy rollup and export, not period timesheets.

TimePillar public materials position live project and epic rollups of estimated vs logged time, variance, percent of budget used, child-work visibility, and PDF/CSV export from the Jira issue sidebar. The product page states it reads native Jira time-tracking fields and does not use a separate data store — verify that claim in trial and on the Marketplace Privacy & Security tab.

At the time of prior verified research on this site (June 2026), the TimePillar Marketplace listing described Jira Cloud rollups; the product page also mentions Data Center — verify your hosting path before rollout. Prior public-source review on this site did not find support for remaining-estimate rollups at parent scope; verify in trial if forecast variance matters.

TimePillar is not a timesheet app. It does not provide period worklog reports by assignee, approval locks, billing rates, or automatic capture. It addresses the steering-deck rollup question when worklogs already exist in Jira.

Evaluate TimePillar when the recurring question is:

"For this epic or project, what did we estimate, what have we logged, where is the variance, and which child issues explain it — without exporting rows first?"

For broader app-category comparison, see TimePillar vs Jira time tracking Marketplace apps.

Pick the Report Job Before You Pick the Tool

Jira reporting is not one feature. It is five recurring questions with different native paths and different gaps.

Use sprint and epic reports for flow. Use JQL and work ratio for triage. Use exports when the meeting is occasional. Add a rollup layer when the same hierarchy total gets rebuilt every sprint. Add a timesheet layer when the period and approval question is the real job.

When you name the report first, the tool conversation gets shorter — and the status update gets closer to Jira instead of a private spreadsheet.

See how Jira time reports in TimePillar help teams bring estimate, logged time, variance, and child-issue rollups closer to the work item — so the five questions start with a current answer in Jira.