> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devperform.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Team & Engineer Metrics

> The core delivery metrics on the team dashboard and how they're calculated.

These are the foundational metrics on the [Team Dashboard](/dashboard/team-view), available on every plan. They're computed from your ingested pull-request data for the selected date range — a PR counts in a period if it was **merged or closed** within that window. Pull requests opened by **automation bots** (Dependabot, Renovate, and similar `[bot]` accounts) are excluded from team throughput, trends, anomaly alerts, and investment allocation — so a dependency-update storm never masquerades as team output. AI **coding agents** (Devin, Copilot coding agent, and similar) are counted: their merged work is real output, tracked separately in the [AI metrics](/metrics/ai-metrics). If a bot in your org uses a regular login (release bots, CI accounts), an admin can flag it — open the engineer's profile on the **People** page and check **Automation bot**. Flagged accounts are excluded from all analytics and never count as billable seats; the People page's **Bots** section is where you review and unflag them.

<Note>
  Looking for DORA, phased cycle time, rework, AI, or investment metrics? Those have their own pages under **Metrics**.
</Note>

## Cycle Time

**Median hours from PR open to merge.** How long work takes to ship once a PR is opened. High cycle time usually means PRs are sitting in review queues or stuck in feedback loops. Displayed as hours (`4.2h`) or days (`1.3d`). For a stage-by-stage breakdown, see [phased cycle time](/metrics/flow#phased-cycle-time).

## Time to First Review

**Median hours from PR open to the first reviewer engagement** — a review event *or* a reviewer comment (on GitLab and Bitbucket, review often happens in comments rather than formal approvals). Isolates the "waiting for a reviewer" portion of cycle time. High cycle time but low time-to-first-review points to the review-to-merge phase; high time-to-first-review means reviewers aren't picking work up fast enough.

## Merge Rate

**Merged PRs ÷ total closed PRs.** A rate well below \~90% is worth a look — PRs may be getting abandoned, superseded, or failing checks. Shown as a percentage.

## PRs Closed

Total PRs closed (merged or not) in the period. Context for activity volume, **not a target**.

## PRs Reviewed

PRs the engineer participated in as a reviewer — a measure of cross-team contribution and knowledge-sharing.

## PR Comments

Total review comments left, including general and inline code comments.

## Change Suggestions

Reviews that requested changes. Context on review rigor, not a per-person score.

## Lines Changed

Additions + deletions across merged PRs. Treat this as context for PR size, **never as a productivity measure**.

## PR Size Distribution

PRs are bucketed by total lines changed (additions + deletions):

| Size | Lines changed |
| ---- | ------------- |
| XS   | under 10      |
| S    | 10–49         |
| M    | 50–249        |
| L    | 250–999       |
| XL   | 1000+         |

Smaller PRs generally get reviewed faster and have lower cycle times. The distribution chart shows each engineer's size habits over the period.

## Team averages

The summary cards show team **averages** (time-based metrics) or **totals** (count metrics) across all visible engineers. Changing the team filter or date range updates them instantly.