Many Span metrics are shown as a rate per week — for example Deployments / week, PRs merged / week, Commits / week, and Weighted PRs / week. This guide explains what those numbers mean, how they are calculated, and how to read them correctly so you can compare teams and time periods fairly.

Key idea: a "/ week" metric is an average rate, not a total. It answers "how much per week, on average?" over the range you selected — so it stays comparable whether you look at 2 weeks or 6 months, and (for per-person metrics) whether the team has 3 engineers or 300.

Why Span shows rates instead of totals

Raw totals are hard to compare. A team that merged 400 PRs might simply be bigger, or you might be looking at a longer window. Expressing a metric "per week" removes two sources of distortion:

• Time window length. The value is normalized by how many days are in your selected date range, so a 90-day view and a 30-day view are directly comparable.

• Team size and time off. For per-person metrics, the value is normalized by how many people were actually working (excluding weekends and out-of-office time), so it reflects throughput per contributor rather than headcount.

The two meanings of "week"

Not every "/ week" metric uses the same definition of a week. There are two families, plus a time-based variant.

Calendar-week rates

These describe how often something happens across the whole team or organization, regardless of how many people are involved.

value = total events ÷ (calendar days in range) × 7

Example — Deployments / week. If you shipped 12 production deployments over a 30-day window:

12 ÷ 30 × 7 = 2.8 deployments / week

These metrics are not divided by team size. Adding more engineers does not change deployment cadence on its own.

Per-active-contributor rates

These describe per-person output. Instead of dividing by calendar days, Span divides by the number of active contributor days — days on which a contributor was actually working — and then scales to a 7-day active week.

value = total (by active contributors) ÷ (active contributor days) × 7

Because the denominator counts only real working days, vacations, holidays, and other out-of-office time do not drag the number down, and the result is already an average per contributor. That means you can compare a large team and a small team directly.

What is an "active contributor"? Someone who, at that point in time, is actively employed, has had commit activity within the last 30 days, is not out of office, and is not excluded from your contributor list in settings. (We recommend excluding managers from your contributor list.)

Example — PRs merged / week. If active contributors merged 90 PRs across 210 active contributor days:

90 ÷ 210 × 7 = 3.0 PRs merged / week per active contributor

Per-person weekly time

Time-based calendar metrics (meeting time, focus time, fragmented time) are averaged over a 5-day work week per person, since meetings are a weekday phenomenon. The idea is the same — a per-person weekly average that ignores weekends and time off.

Weighted PRs / week (a.k.a. Velocity), explained

This is the most commonly misread "/ week" metric, because the numerator is weighted rather than a simple count. It answers: "How much substantive pull-request work does an active contributor ship per week?"

Instead of counting each PR as 1, Span gives every merged PR a weight between 0 and 2, where 1 represents a PR of average size and complexity. The weight is the sum of two parts:

A few important details:

• Lines are counted after excluding the file patterns you have configured to ignore in admin settings (for example generated files or lockfiles), so boilerplate does not inflate the score.

• The size score is logarithmic, so a 2,000-line PR is not worth twice a 1,000-line PR — both are capped at 1 on the size component. This deliberately limits the reward for very large PRs.

• Weighted PRs are then summed across a contributor's active days and divided by active contributor days × 7, exactly like the other per-contributor rates.

PR weight         = complexity (0–1) + size (0–1)          → 0 to 2, average ≈ 1
Weighted PRs/week = Σ(PR weights on active days) ÷ (active contributor days) × 7

Why weight PRs at all? A raw PR count rewards splitting work into many tiny pull requests. Weighting by size and complexity rewards substantive work instead and makes the metric harder to game. This is why Weighted PRs / week and PRs merged / week can differ: a team that ships a few large, complex PRs can have a higher weighted value than its raw count, and a team of many trivial PRs can have a lower one.

Quick reference: what each "/ week" metric means

How to read a "/ week" number correctly

• It is an average, not a running total. Multiplying "PRs merged / week" by the number of weeks will not exactly reproduce the total, because the denominator counts active working days, not whole calendar weeks.

• Changing the date range is safe. A rate is normalized by the length of the window, so a longer range does not automatically produce a bigger number — it stays comparable.

• Per-contributor rates already account for team size. Adding engineers does not inflate them; they reflect output per person. To see totals instead, use the corresponding "Total …" metric.

• Out-of-office time is excluded from per-contributor and time-based metrics, so vacations and holidays do not distort the average.

• Weighted PRs is a relative score, not a count or a number of hours. A value of 1 means roughly one average-sized, average-complexity PR. Compare it over time and against benchmarks rather than reading it as a literal PR count.

Troubleshooting