Sprint velocity calculations exclude subtasks in burndown chart

ALM Atlassian Jira Software
, , , , , , , ,
1

We’re running Jira 9 and have a critical issue with our sprint velocity reports. The burndown chart is excluding all subtask story points from velocity calculations, which makes our sprint forecasting completely unreliable.

Our team structure requires subtasks for implementation tracking, and we estimate at the subtask level (parent stories are containers). The velocity report only counts parent story points, showing artificially low velocity.

I’ve checked the sprint velocity configuration settings and subtask issue type mapping, but can’t find where to include subtasks in calculations. Our JQL filtering seems correct:

project = DEV AND sprint = 45 AND issuetype in (Story, Task, Subtask)

The burndown chart scope appears limited to parent issues only. How do we configure Jira to include subtask estimates in sprint velocity and burndown calculations?

2

I’ve seen this before. The issue is that Jira’s native velocity calculation doesn’t aggregate subtask estimates by default. Check your board configuration under “Estimation” settings - there’s a specific option for whether to use parent or subtask estimates. You might have it set to “Story Points” field on parent issues only.

3

Actually there’s a configuration that handles this properly. Look at your board settings under “Estimation” - you can set the estimation statistic to use either “Issue Count”, “Story Points”, or “Original Time Estimate”. More importantly, check if you have “Sum of story points” enabled for parent issues. This should aggregate subtask estimates automatically if configured correctly in your field configuration scheme.

4

The root cause is how Jira handles the burndown chart calculation scope versus velocity aggregation. Here’s the complete solution:

1. Sprint Velocity Configuration Settings: Navigate to Board Settings → Estimation and verify your “Estimation Statistic” field. If you’re estimating at subtask level, you need a custom field that aggregates subtask points to parents. The native “Story Points” field doesn’t auto-sum from subtasks.

2. Subtask Issue Type Mapping: Create a calculated custom field (requires ScriptRunner or similar) that sums child story points:

issue.getSubTaskObjects()*.getCustomFieldValue(storyPointsField).sum() ?: 0

Set this as your board’s estimation statistic instead of the standard Story Points field.

3. JQL Filtering for Estimation Validation: Your JQL is correct but won’t affect velocity calculation. The board’s estimation statistic setting controls what’s counted. Verify subtasks have the Story Points field populated:

project = DEV AND sprint = 45 AND "Story Points" is not EMPTY AND issuetype = Subtask

4. Burndown Chart Calculation Scope: The burndown chart uses the same estimation statistic as velocity. Once you configure the aggregated field, both reports will include subtask estimates. Go to Board Settings → Columns and ensure subtasks are visible in your workflow columns - hidden subtasks won’t appear in burndown calculations even if estimated.

Alternative Approach: If you can’t use calculated fields, restructure your estimation model: estimate parent Stories with the sum of planned subtask work, and leave subtasks unestimated (use them purely for task breakdown). This aligns with Jira’s native velocity tracking model and eliminates the aggregation issue entirely.

The key insight is that Jira’s velocity calculation is field-based, not hierarchy-aware by default. You must explicitly configure aggregation through calculated fields or change your estimation approach to work with the platform’s design.