Issue Completion Rate Report
Last updated: October 27, 2026
Issue Completion Rate is the share of issues in a date range that are done: issues completed in the range divided by those issues plus the open issues created in the range.
Why it matters
The rate shows whether a team finishes the work it takes on or accumulates work in progress. A low or falling rate can point to overcommitment, bottlenecks in a workflow stage, or work abandoned midway. Higher is better. Use it to track flow health, check delivery reliability, and measure the effect of process changes.
How it works
Issue Completion Rate = Done issues ÷ All issuesSpan maps each issue's current status to To Do, In Progress, or Done, using your tracker's status categories. It supports Jira, Linear, Azure Boards, and GitHub Issues.
Span places each issue in time. Done issues land on their completion date. Open issues (To Do or In Progress) land on their creation date.
For the date range, Span counts done issues and all issues that land in it, and divides. With no issues, the rate is 0%.
Every issue type counts, including stories, tasks, bugs, and sub-tasks. Values show as a percentage, and benchmark percentile ranks are available.
Setup
No setup is needed once an issue tracker is connected. Find the metric in Insights → Productivity → Velocity → Issue lifecycle, and in custom reports and dashboards.
Filters and controls:
Time: custom date ranges or presets, granularity (day, week, month, quarter), and comparison with a previous period.
People: IC level, job title, job family, location, active status, tenure, and tags.
Teams: team or group hierarchy.
Work: issue type.
Filter settings are saved between sessions.
Things to know
Worked example: in March, a team completed 40 issues. It also created 20 issues in March that are still open, and has 50 older issues still open from earlier months. The rate is 40 ÷ (40 + 20) = 67%. The 50 older open issues don't count, because open issues land on their creation date.
Recent periods read low: most issues created last week are still open, so the rate climbs as they close.
Old backlog doesn't count against you: a Jira filter of "all issues open during the period" includes old open tickets; Span doesn't.
Canceled work counts as done: Linear Canceled, Azure Boards Removed, and GitHub "won't do" statuses map to Done and raise the rate. In Jira, it depends on which category your canceled status sits in.
Unmapped statuses: issues with no mapped status count in the denominator but never as done.
Assigned issues only: report views count issues assigned to someone Span can match to a person. Unassigned backlog items don't lower the rate.
Not a sprint metric: this rate ignores sprints. For sprint commitment, use planning accuracy in Sprint Tracking.
A consistent 100% can mean the team only tracks work that's already done, or closes issues without moving them through the workflow.
What "good" looks like depends on your backlog practices. Some teams keep large backlogs for long-term planning, which lowers the rate. Watch your own trend and compare against benchmarks rather than a fixed target.
Rate versus throughput: Issues Completed / Week measures output per person. Completion rate measures what share of work reaches done. A team can have high throughput and a low completion rate if it creates issues faster than it closes them.
Reading it with other metrics. High Time in To Do plus a low completion rate suggests a prioritization or capacity problem. High Time in In Progress plus a low completion rate suggests an execution bottleneck. Issue cycle time measures time spent in In Progress statuses, so it shows how long active work takes once it starts.
Related articles
Total Story Points Completed Report
Need help?
Contact your Span account team or reach out to support@span.app.