I was recently asked how to report on subtasks in Jira. My knee-jerk question back was: Why? This question raises a sometimes-heated agile debate, but I will save that for the end. Answers first, we can debate after! đ
Visibility of Subtasks in Jira
Jiraâs native agile reporting is centered on parent work items (stories, tasks, and epics). This is the source of much of the confusion. Below is a quick summary of the most used agile reports and viewing options:
 Report or Feature |  How Subtasks Behave | What it means |
|---|
Sprint Report | Primarily focused on parent work items | Useful for sprint outcome reporting, but not ideal for subtask-level progress analysis |
Burndown and Velocity views | Built around board estimation settings and parent work items | Subtasks are not usually the main reporting unit for velocity-style analysis |
Board view | Subtasks can be visible under their parent | Helpful for day-to-day execution, but not a management report by itself |
Work item search & JQL | Subtasks are fully searchable | This is the most flexible native way to report on them |
 Dashboards | Subtasks can be shown through saved filters and gadgets | Best native option for building repeatable subtask reporting |
The key takeaway is simple: Jira can report on subtasks, but theyâre not the focus in classic agile reports. If you need deeper visibility, you usually get there through filters, dashboards, and careful workflow design.
How to Report on Subtasks in Jira
1. Use JQL to isolate subtasks
JQL is the foundation of most useful subtask reporting in Jira. Once you can reliably find the right subtasks, you can save that JQL query to a filter and use that in dashboards, team views, and operational reports.
Common examples include:
- Which subtasks are assigned to me in the current sprint?
issuetype = Sub-task AND sprint in openSprints() AND assignee = currentUser()
- Which subtasks are still in progress or not started?
issuetype = Sub-task AND statusCategory != Done ORDER BY assignee, priority DESC
- What is the execution status inside a specific parent work item?
issuetype = Sub-task AND parent = ABC-123
2. Turn saved filters into dashboards
Once you have a strong JQL filter, dashboards become the easiest way to make subtask reporting visible to others.
- Filter results gadget for a straightforward list of subtasks with assignee, status, priority, and parent
- Two-dimensional filter statistics to compare subtasks across two dimensions, such as assignee by status
- Pie chart gadget to show subtask distribution by assignee, status, work item type, or priority
This approach is especially effective for team leads, scrum masters, and delivery managers who need a lightweight operational view without moving into Marketplace reporting apps.
3. Report on blocked or incomplete work inside parent work items
One of the best reasons to report on subtasks is to expose hidden execution risk. A parent story may still look healthy at a glance, while an important subtask is stuck in review, waiting on another team, or not yet started.
Useful subtask JQL filters turned into reports often focus on:
- Open subtasks under in-progress stories
- Blocked subtasks by assignee or component
- Subtasks not updated recently
- Subtasks in the current sprint that have not started
This kind of reporting is less about formal Agile metrics and more about practical flow management.
Best Practices for Subtask Reporting
- Be clear about the purpose. Decide whether you want forecasting, effort tracking, execution monitoring, or accountability. Different goals require different metrics.
- Keep the parent work item as the primary value unit. Even when you report on subtasks, stakeholders usually still need the story or task to remain the main business context.
- Avoid using subtask counts as a performance metric. More subtasks do not mean more value, more complexity, or more productivity.
- Use subtasks to reveal flow, not just activity. The best reports identify blockers, ownership gaps, and aging work.
- Review your hierarchy design. If your reporting depends more on subtasks than stories, your work item breakdown may need rethinking.
Now for the Debate, grab your popcorn!
Why is there a debate about reporting on subtasks? Here are the reasons for both sides:
đđ» A subtask is usually just a breakdown of work inside a parent story or task. It helps the team coordinate delivery, split effort across people, and track execution during a sprint. In that view, the parent work item is the real reporting unit, and subtasks are simply working notes with a workflow.
đ But in practice, many Jira teams do care about subtask-level reporting. They want to know who is doing what, which pieces of a story are blocked, whether work is distributed evenly, and where execution is getting stuck. For service, operations, platform, or hybrid delivery teams, subtasks can represent meaningful work that deserves visibility.
The real question is not whether reporting on subtasks is universally right or wrong. The better question is: what job are subtasks doing for your team?
A Practical Conclusion
So, should you report on subtasks in Jira?
Maybe. Sometimes.
If subtasks are simply a teamâs internal checklist for completing a story, reporting on them will add little to no value. So, keep reporting focused on the parent work item and use subtasks only to support delivery.
But if subtasks represent meaningful, assigned work and help your team understand progress, risk, or workload distribution, then reporting on them is entirely reasonable. Jira will not do all of that for you in its standard agile reports, but with JQL, saved filters, and dashboards, you can build useful native views without much effort.
TLDR: The healthiest position is not always report on subtasks or never report on subtasks. It is this: report at the level where the insight is useful.
