Issue Throughput Report

Last updated: October 27, 2026

The Issue Throughput report shows how many issues one person on your team completes in a typical week. The metric behind it is Issues completed / week: completed issues divided by the person-days your people were available, times 7.

Why it matters

Raw issue counts drop whenever people take time off or a team shrinks. Issues completed / week removes out-of-office (OOO) days from the count of available days, so you can compare weeks, teams of different sizes and holiday periods fairly.

For engineering managers: set realistic sprint commitments from what the team actually finishes, and see whether a process or tooling change moved delivery.
For leaders: compare capacity across teams and check your rate against peer organizations with percentile benchmarks.
For planning: forecast how long a backlog will take (see the example under Things to know).

How it works

What the report shows

Chart: Issues completed / week over your date range, one point per interval. Select a point to see the completed issues behind it.
Related reports: cards for Issue Completion Rate, Estimate completed / week and PR Link Rate, with the same filters applied.
Table: the same value broken down by team or person, so you can compare them side by side.
Controls: date range and interval, team and people selection, filters on person attributes such as IC level, job title, job family, location and tenure, Group by, comparison to a previous period, and benchmarks.

The value has one decimal place and reads as issues per person per week. Higher usually means faster throughput.

The calculation

Issues completed / week = completed issues ÷ available person-days × 7

Span adds up the completed issues and the available person-days for everyone in scope, divides the totals and multiplies by 7. A team's value is not an average of each person's rate, so people who were available more days weigh more. If no one was available in the range, the report shows 0.

Which issues count as completed

Span reads issues from Jira, Linear, GitHub Issues and Azure Boards. An issue counts when its current status maps to Done:

Jira: statuses in the Done status category.
Linear: Completed and Canceled statuses.
Azure Boards: states in the Completed or Removed category.
GitHub Issues: statuses named like done, completed, closed, canceled or won't do.

Span places each issue on its completion date, or on its creation date when the tracker has no completion date. Every issue type counts, including epics, sub-tasks, bugs and custom types. Each issue is credited to one person, chosen from everyone ever assigned to it who matches a person in your organization: the most recently assigned person marked Contributor, or, if none of them is a Contributor, the most recently assigned of the rest. Issues with no matched assignee don't appear in the report.

What counts toward available person-days

Every person in scope adds one person-day for each calendar day between their start date and termination date that isn't an OOO day. Weekends count, which is why Span multiplies by 7. Contributor status and recent commit activity don't matter here: managers and people who don't write code add days too, as long as they're in the team or filter you're viewing. Terminated members are left out unless you turn on showing them in the display settings.

How Span decides a day is OOO

Calendar (default source): a weekday is OOO when out-of-office calendar events cover more than 4 hours between 8am and 6pm in the person's local time. Exactly 4 hours doesn't count.
HRIS source: every weekday inside an absence counts as OOO, with no hours rule.
Weekends are never OOO.

OOO days leave the available person-days. Issues completed on an OOO day stay in the completed count.

How teams are counted

Span uses current team membership. When you view a team, it counts issues assigned to people who are on that team today, and those people's available days. A person on two teams counts in each team's value, and once at the organization level.

Finding the report

Go to Productivity in the main navigation.
Under Velocity, open Issue lifecycle.
Select the Issue Throughput card.

You need an issue tracker connected (Jira, Linear, GitHub Issues or Azure Boards) and permission to view issue tracking reports. You can also add Issues completed / week to custom dashboards.

Things to know

Worked example: a team of 5 over 2 weeks has 5 × 14 = 70 person-days. One person is OOO for 3 weekdays, so the team has 70 − 3 = 67 available person-days. The team completes 40 issues, 2 of them by the person on an OOO day; those 2 still count. Issues completed / week = 40 ÷ 67 × 7 = 4.18, shown as 4.2.
It's per person, not per team: multiply by headcount for a weekly team total. A team of 4 averaging 5.2 completes about 4 × 5.2 = 20.8 issues a week, so a 52-issue backlog takes about 52 ÷ 20.8 = 2.5 weeks.
It won't match Jira's resolved count: Jira counts every resolved issue. Span counts issues with a matched assignee and divides by available days. For a plain count, see the Done card in the Global statuses view of the Issue lifecycle page.
Weekend exclusion doesn't change it: that setting changes durations such as cycle time. The 7-day multiplier already accounts for weekends.
Status mapping here is the tracker's: the Global statuses and Mapped statuses views on the Issue lifecycle page, and the statuses you map there, don't change which issues count as completed.
Canceled work can count: in Linear, Azure Boards and GitHub Issues, canceled or removed issues count as completed. In Jira it depends on the status category.
Reopened issues: an issue that's open today doesn't count. When it closes again, it counts on its new completion date.
Sub-tasks raise the count: a story split into three sub-tasks counts as four issues. Compare teams that slice work the same way.
Per-type versions (Jira only): Story, Task, Bug, Sub-task and Epic Issues completed / week count one Jira issue type each. Add them to custom dashboards. Custom issue types match none of them.
Company holidays count as available days unless they appear as OOO calendar events or HRIS absences for each person.
Read it with other metrics: Issue Completion Rate shows how much of the work taken on gets finished, Estimate completed / week weighs issues by size, and issue cycle time shows whether a change comes from speed or from how work is sliced. Very high throughput can mean issues are too small or closed without being worked; a sudden drop is worth checking against OOO and team changes.