Jira Velocity Chart Wrong? 7 Fixes for Inaccurate Sprint Velocity in 2026

A Jira velocity chart wrong diagnosis in 2026 almost always traces to one of seven root causes, and the frustrating part is that Jira does not flag any of them as errors — the chart renders normally, the numbers look plausible, and teams plan their next sprint capacity against data that is silently incorrect. This guide diagnoses each failure mode and provides the specific configuration or process fix required to get your velocity data accurate again. We cover the causes that existing guides miss: subtask point architecture, mid-sprint estimate changes, and the board filter scope issue introduced by Jira’s 2025 board configuration updates.

How Jira Calculates Velocity: What the Chart Actually Measures

Before diagnosing inaccuracies, it is worth being precise about what Jira’s velocity chart actually measures, because the definition has a few non-obvious properties that are the root of most accuracy problems.

Jira’s velocity chart plots two values per sprint: Commitment (the total story points of issues in the sprint when the sprint was started, or at any point it was active) and Completed (the total story points of issues moved to a “Done” status column before the sprint was closed). The chart does not measure what was planned at sprint planning — it measures what was in the sprint at the moment the sprint was closed, plus what was added during the sprint.

Key implications:

• If you change a story point estimate after a sprint starts, the commitment figure changes retroactively.
• If you add an issue to a sprint after starting it, the commitment figure increases immediately.
• If you close a sprint with incomplete issues and move them to the next sprint, those points disappear from the original sprint’s completed total — they do not reduce the commitment figure.
• The velocity chart reflects the board’s filter scope — if the board filter includes issues from multiple teams or projects, velocity is a blended number that represents no individual team’s actual performance.

For official documentation on how the velocity chart is constructed, see the Atlassian velocity chart documentation.

Fix 1: Subtask Story Point Double-Counting

This is the most common cause of inflated velocity and the hardest to self-diagnose because the inflation is gradual and looks like team improvement rather than a data error.

The problem: Jira’s default estimation behavior for team-managed projects counts story points on both parent stories and their subtasks. If a story is estimated at 5 points and has two subtasks estimated at 2 and 3 points respectively, closing all three issues in a sprint contributes 10 points to velocity (5 + 2 + 3) instead of the intended 5. On a sprint with 20 stories and average subtask coverage, this can double reported velocity.

1. Check your board’s estimation field configuration — navigate to Board Settings → Estimation. The “Estimation statistic” field shows what metric the board uses for velocity calculation. If this is set to “Story Points” and your team uses subtasks with their own point estimates, you have a double-counting risk.
2. Audit a recent sprint for double-counted issues — open the velocity chart and click on a completed sprint bar to see the issue breakdown. Export the issue list and filter for issues with parent stories in the same sprint. Any subtask in the same sprint as its parent story is double-counted.
3. Resolve by choosing one level for estimation — the correct fix depends on your workflow: (a) Estimate at the story level only and set all subtask point fields to 0, or (b) Estimate at the subtask level only and leave parent stories at 0. Do not estimate at both levels. This decision should be documented in your team’s Definition of Ready.
4. For company-managed projects: navigate to Project Settings → Features → Estimation. Set the estimation field to the level you want to count. In company-managed projects, you can configure whether sub-tasks are included in parent story estimates or tracked separately.
5. Correct historical data — for sprints already closed with double-counted data, there is no automated retroactive fix. You will need to manually note the inflation factor for those sprints when using them in capacity planning. Going forward, the fix above prevents new double-counting.

Fix 2: Mid-Sprint Estimate Changes Corrupting Baselines

Changing story point estimates after a sprint has started is the most direct way to corrupt velocity data, and it is a surprisingly common practice on teams that treat estimates as living values rather than sprint commitments.

The impact: Jira recalculates the sprint’s commitment total any time a point estimate changes on an active sprint issue. A sprint planned at 40 points where three stories are re-estimated upward to 55 points during the sprint will show 55 points committed and — if all are completed — 55 points completed. The velocity chart will show a higher velocity for that sprint than the team actually had capacity for, inflating the rolling average that drives the next sprint’s capacity plan.

1. Audit for mid-sprint estimate changes — in Jira, navigate to a completed sprint’s issues list. For each issue, click History in the issue detail panel and filter for changes to the “Story Points” field. Any change timestamped after the sprint start date is a mid-sprint estimate change.
2. Establish a team policy against mid-sprint re-estimation — the fix is primarily behavioral, not configuration-based. Estimate changes should only occur at sprint planning, not during the sprint. If scope genuinely changes during a sprint (a story turns out to be larger), the correct action is to split the story, move the excess to the backlog, and complete only the originally estimated scope in the current sprint.
3. Use the “Original Estimate” field as a guard rail — in company-managed projects, enable the Original Estimate field (separate from Story Points). Teams can then distinguish between what was committed at sprint start and what the current estimate is, without the current estimate affecting the velocity calculation. Note: this requires a custom velocity configuration to use Original Estimate as the commitment metric rather than current Story Points.
4. Lock sprint issues at sprint start via automation — configure a Jira automation rule that triggers when a sprint starts: When sprint starts → For each issue in sprint → Post a comment: “Sprint locked — estimate changes require Scrum Master approval.” This creates a social friction point that reduces casual re-estimation without fully blocking it.

Fix 3: Re-Opened Issues Attributed to the Wrong Sprint

When a sprint is closed with incomplete issues, Jira moves those issues to either the backlog or the next active sprint. The original sprint records those issues in its Commitment total but not in its Completed total — this is correct behavior. The problem arises when an issue that was “Done” in a closed sprint is re-opened later (typically due to a bug report or review failure). Jira attributes the re-opened issue’s points to the sprint in which it is currently active, not the sprint in which it was originally completed, creating a phantom point drop in the current sprint.

1. Identify re-opened issues in the velocity chart anomaly — if you see a sprint with an unusually low completion rate despite the team reporting normal output, check for re-opened issues. In the sprint’s issue list, filter for issues with the “Re-opened” status or look for issues where the Status field changed from Done to any In Progress status after the sprint closed.
2. Use “Won’t Fix” or “Invalid” instead of re-opening — for issues that are determined to be invalid after a sprint closes, close them as “Won’t Fix” or “Invalid” rather than reopening and re-assigning. This preserves the original sprint’s velocity data.
3. Create a separate “Defect Sprint” or bug-fix board — for legitimate re-work, consider routing re-opened issues to a dedicated bug-fix board or a separate sprint rather than the active feature sprint. This keeps feature velocity data clean and tracks rework separately, which is more useful operational data anyway.
4. Document the re-open in the sprint notes — Jira does not have a native sprint narrative field, but the sprint goal field can be used to note anomalies: “Sprint velocity lower than expected due to 2 re-opened issues from Sprint 14 (8 points re-attributed to this sprint).” This preserves institutional knowledge for retrospectives and capacity planning.

Fix 4: Issues Added After Sprint Start Skewing Commitment Totals

Issues added to a sprint after it starts are included in the sprint’s commitment total immediately. This is intended behavior — Jira is recording what the sprint actually committed to, including scope changes. The problem is that these mid-sprint additions skew both the commitment total and, if not completed, the completion rate, making velocity comparisons across sprints unreliable.

1. Track sprint scope changes in the Sprint Report — Jira’s Sprint Report (separate from the Velocity Chart) distinguishes between issues committed at sprint start and issues added after the sprint started. Use this view to identify sprints where mid-sprint additions are distorting the velocity chart.
2. Establish a “no additions after Day 1” policy — the most effective fix is process-based: define a team agreement that issues can only be added to a sprint during the first 24 hours after sprint start (to accommodate planning meeting stragglers) and not after that. Document this in your team working agreement.
3. When additions are unavoidable, record them — if urgent work genuinely must be added mid-sprint, remove an equivalent amount of planned work from the sprint to maintain commitment parity. This keeps the velocity chart meaningful as a capacity signal even when scope changes occur.
4. Use the “Added after sprint start” filter in Sprint Report — when doing capacity planning, open the Sprint Report for the last 5 sprints and check the “Added after sprint start” section. If this section consistently has 3+ issues per sprint, your team has a planning process problem that is upstream of the velocity inaccuracy — fix sprint planning fidelity before trying to interpret velocity trends.

Fix 5: Mixed Sprint Durations Making Historical Data Incomparable

A velocity chart that compares a 3-week sprint to a 2-week sprint is comparing apples to oranges. The commitment and completion totals are not normalized for duration, so a team that moved from 3-week to 2-week sprints will appear to have lower velocity in recent sprints even if their per-day throughput is identical or higher.

1. Identify mixed durations in your velocity chart — open the velocity chart and hover over each sprint bar. The sprint date range is shown in the tooltip. If sprint durations vary, you have a mixed-duration chart.
2. Calculate normalized velocity manually — divide each sprint’s completion total by the number of working days in the sprint to get a per-day velocity. Compare per-day velocities rather than absolute totals when sprint durations are mixed. Jira does not do this normalization automatically.
3. Set a clean start date for post-transition data — if your team recently changed sprint duration, establish a start date from which velocity comparisons will be made only against sprints of the same duration. Exclude all pre-transition sprints from capacity planning calculations going forward.
4. Consider creating a new board for post-transition tracking — if the sprint duration change was significant and permanent (e.g., 3-week to 2-week), creating a new Jira board starts a fresh velocity history without the mixed-duration noise. The old board and its history remain accessible for reference.

Fix 6: Multi-Team Board Configuration Polluting Velocity Data

A Jira board that includes issues from multiple teams — whether through a broad project filter or a shared project — generates a velocity chart that reflects the blended output of all teams. This blended velocity is not a useful planning input for any individual team and is a common cause of “our velocity looks wrong” complaints from teams that share a board with another team or sub-team.

1. Check your board’s project filter — navigate to Board Settings → General → Filter. Review the JQL filter that defines which issues appear on the board. If the filter includes multiple projects or uses a broad label/component filter, it may be including issues from teams other than the one you are trying to measure.
2. Create team-specific boards — the correct fix for multi-team boards is to create separate boards for each team with filters that are explicitly scoped to that team’s issues. Use a team label, component, or assignee-based filter to segment the data.
3. Use a shared project with team-specific sprints — if your organization requires a single project for all teams, use Jira’s sprint naming convention to distinguish team sprints: “Team A Sprint 1” vs. “Team B Sprint 1.” Each team’s board can filter for their sprint prefix, giving each team a clean velocity chart while sharing project infrastructure.

Fix 7: Jira Velocity Chart Wrong 2026 — Board Filter Scope Issues

The 2025 Jira board configuration update changed how board filters interact with the velocity chart in team-managed projects. Specifically, if a board filter was set before the 2025 update and includes a saved filter object (rather than inline JQL), the velocity chart may be using a cached filter state that does not reflect your current board scope. This is a 2025/2026-specific issue that affects teams who have had boards in production for more than 18 months without reviewing the filter configuration.

1. Identify if you have a stale saved filter — navigate to Board Settings → General → Filter. If the filter field shows a filter name (e.g., “My Team Filter”) rather than inline JQL, you are using a saved filter. Click “Edit filter” and check the last-modified date of the saved filter.
2. Verify the saved filter scope is current — compare the filter’s project scope against your actual current project list. If your team has added projects since the filter was last updated, the velocity chart may be missing issues from those projects — or including issues from decommissioned projects.
3. Convert to inline JQL — in Board Settings, replace the saved filter reference with inline JQL that explicitly defines your current scope. Inline JQL updates immediately when changed and does not have the caching behavior of saved filters. Example: project in (PROJ1, PROJ2) AND sprint in openSprints()
4. Regenerate velocity chart data — after updating the board filter, close and reopen the velocity chart. Jira does not retroactively recalculate closed sprint data when a filter changes, but future sprints will use the corrected scope. For retroactive accuracy, use Jira’s export and reporting API to pull sprint data with the corrected filter applied to historical sprints.
5. Document your board filter — add a description to the board (Board Settings → General → Board Description) explaining the filter scope, the last review date, and which teams and projects it covers. This prevents the filter drift that causes this issue from recurring.

For additional context on Jira reporting accuracy and sprint metrics, see our Jira sprint reporting guide for 2026, our Jira Plans setup guide, and our Jira automation rules guide. For official Jira board and sprint configuration reference, see the Atlassian board configuration documentation.

Frequently Asked Questions

Why does my Jira velocity chart show higher velocity than my team actually completed?

Inflated velocity most commonly results from subtask story point double-counting (both parent stories and subtasks have point estimates and both are counted), mid-sprint estimate increases that raised the completion total, or issues from other teams being included in your board’s filter. Start by auditing whether your board counts points at the story level, the subtask level, or both — fix the estimation hierarchy first before looking at other causes.

Why does my Jira velocity chart show lower velocity than expected?

Lower-than-expected velocity typically results from: re-opened issues from previous sprints being attributed to the current sprint (reducing completion relative to commitment), incomplete issues from sprint start being carried over and not replaced with equivalent scope, or a board filter that recently changed scope to include more projects, diluting velocity with teams that complete fewer points. Check the Sprint Report for the affected sprint to see exactly which issues were completed, added after start, and incomplete at close.

Can I fix historical velocity data in Jira?

Jira does not provide a native way to retroactively edit closed sprint velocity data. The velocity chart reflects the historical record of what was committed and completed at the time each sprint closed. You can correct the root cause going forward, but historical sprint data is permanent. For teams that need accurate historical baselines for capacity planning, the practical approach is to manually calculate corrected velocity for the affected sprints using exported issue data and note the corrected figures in your planning documentation outside of Jira.

Does changing the board filter affect historical velocity data?

Changing the board filter does not retroactively change closed sprint data in the velocity chart. Historical sprints continue to show the velocity calculated based on the filter that was active when those sprints were running. Only future sprints will use the updated filter scope. If your filter change significantly narrows or expands scope, you should treat pre-change and post-change velocity data as separate series for capacity planning purposes.

How many sprints should I include in velocity calculations for capacity planning?

Atlassian recommends using the last 3–7 sprints for velocity-based capacity planning. Fewer than 3 sprints is statistically unreliable; more than 7 sprints includes data that is too old to reflect the team’s current capacity and skill mix. If your team recently changed composition (new members, departures) or sprint duration, restrict your velocity sample to sprints completed after the change. The default Jira velocity chart shows 7 sprints — this is a reasonable starting point, but you may want to narrow it to 3 or 4 if your team has been through significant changes in the last few months.