Reporting on Subtasks in Jira

[#1]

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

1. Be clear about the purpose. Decide whether you want forecasting, effort tracking, execution monitoring, or accountability. Different goals require different metrics.
2. 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.
3. Avoid using subtask counts as a performance metric. More subtasks do not mean more value, more complexity, or more productivity.
4. Use subtasks to reveal flow, not just activity. The best reports identify blockers, ownership gaps, and aging work.
5. 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.

[Bill Sheboy]

Hi @Peggy Graham 

Thanks for your article.  Yes, and...on the debate stuff.

Long ago (in agile timespan years), teams solved needs like this by placing the "burn down" chart (showing cumulative effort forecast values completed over time) next to the "burn up" chart (showing cumulative count / value forecast values delivered over time) side by side, creating the "agile-V" shape to detect problems.  Common patterns on such paired charts were called "sprint signatures".  And thus even when work was broken down into sub-units (i.e., not individually releasable to production), progress could be assessed by multiple measures to find symptoms of problems faster...and take action.

The "Project Management camp" might say the left chart matters more and the "Product Management camp" (or Kanban participants) might say the right one did.  Depending upon what was in the tradeoff matrix for the delivery, both helped sustainably deliver value to customers.

Kind regards,
Bill

[Peggy Graham]

Thank you, @Bill Sheboy, for adding the agile-V!  I agree that both are valuable and needed, but I've certainly seen folks who lean towards one or the other...

Maybe we can have a future article on my other favorite agile debate: work committed to a sprint that didn't get done IN that sprint. I've seen some pretty, um, strong opinions on different ways to handle that! 😂