Estimate Completed / Week Report

Last updated: October 27, 2026

The Estimate completed / week report shows how many story points (or other estimate units) one person on your team completes in a typical week. The metric behind it is Estimate completed / week: the estimates on completed issues divided by the person-days your people were available, times 7.

Why it matters

Issue counts treat a one-line fix and a two-week feature the same. Estimate completed / week weighs each completed issue by your team's own estimate, so it shows effort delivered rather than activity. Like Issue Throughput, it 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 sprint commitments in points from what the team actually finishes, and see whether a process or tooling change moved delivery.
For leaders: compare capacity across teams that estimate on the same scale, and check your rate against peer organizations with percentile benchmarks.
For planning: forecast how long an epic or backlog will take in points (see the example under Things to know).

How it works

What the report shows

Chart: Estimate 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 Throughput, Issue Completion Rate 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 estimate points per person per week. Higher usually means more estimated work finished.

The calculation

Estimate completed / week = sum of estimates on completed issues ÷ available person-days × 7

Span adds up the estimates on 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, or no completed issue has an estimate, the report shows 0.

Which issues count as completed

The same issues as Issue Throughput. 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 with an estimate 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.

Which estimate Span reads

Jira: one story point field for your Jira site. Span detects it automatically: the field named Story Points or the field named Story point estimate. When your site has both, Span uses the one with more change history. Jira's time-tracking estimates (Original estimate, Remaining estimate) aren't used.
Linear: the issue's Estimate.
Azure Boards: the Story Points field. Effort and Size aren't read, so work items that only use those fields count as 0.
GitHub Issues: GitHub Issues has no estimate field Span reads, so these issues count as 0.

Span uses each issue's latest estimate, not the estimate at sprint start. An issue with no estimate, or whose estimate was cleared, adds 0 points but stays in Issue Throughput.

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, and their estimates, stay in the total.

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 Estimate completed / week card.

You need an issue tracker connected (Jira, Linear, GitHub Issues or Azure Boards), estimates on your issues, and permission to view issue tracking reports. To leave out OOO days, connect an OOO source (calendar or HRIS). You can also add Estimate completed / week, and Total Estimate Completed (the plain sum of points on completed issues, with no per-week division), 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. 32 of them carry estimates totaling 94 points, including 2 issues worth 5 points that the OOO person closed on an OOO day; those still count. The other 8 issues have no estimate and add 0. Estimate completed / week = 94 ÷ 67 × 7 = 9.82, shown as 9.8. Issue Throughput for the same team is 40 ÷ 67 × 7 = 4.2.
Missing estimates lower the value: in the example above, if the 8 unestimated issues had been estimated at 3 points each, the total would be 94 + 24 = 118 points and the value 118 ÷ 67 × 7 = 12.3 instead of 9.8. Before relying on this metric, check how many of your completed issues carry an estimate. If coverage is low, use Issue Throughput instead.
It's per person, not per team: multiply by headcount for a weekly team total. A team of 4 averaging 9.8 completes about 4 × 9.8 = 39.2 points a week, so a 180-point epic takes about 180 ÷ 39.2 = 4.6 weeks.
It won't match Jira's velocity chart: Jira reports per sprint and per board, uses the estimate at sprint start for commitment, and ignores sub-task estimates. Span sums the latest estimate on every completed issue in your date range, sub-tasks included, and divides by available person-days. For per-sprint numbers, see the Sprint Tracking report, which uses each issue's estimate at the end of the sprint.
Re-estimating changes history: Span uses each issue's latest estimate, so changing the points on a completed issue changes past weeks too.
Points on parents and children both count: if your team estimates an epic or story and also its sub-tasks, both sets of points are added. Estimate at one level to avoid counting the same work twice.
Compare teams with care: a point means different things on different teams. Compare teams only when they estimate on the same scale, and use the metric mainly to track one team over time.
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 and Azure Boards, canceled or removed issues with an estimate add their points. 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.
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 Throughput shows how many issues get finished, so high throughput with a low estimate rate means many small issues. Issue Completion Rate shows how much of the work taken on gets finished, and issue cycle time shows whether a change comes from speed or from issue size. A sudden rise can mean estimates are inflating; a sudden drop is worth checking against OOO, team changes and estimate coverage.