Submitter metrics live inside the Team Collaboration Network tab of the Performance Delivery dashboard. They focus on what PR submitters do to move a pull request toward merge, so you can see where author-side actions are helping (or holding up) the review cycle.
All submitter metrics use calendar hours. Bot accounts are excluded unless explicitly mapped as a user in Leanmote. Draft PRs are included once merged.
The four sub-metrics
Iterated PRs — the percentage of merged pull requests that had at least one follow-on commit, expressed as a whole-number percentage. A "follow-on commit" is any commit pushed after the PR was created — it does not require a reviewer to have commented first. A high number means PRs are routinely revised after first submission, which is normal in code review; a very high number can mean PRs are landing too early.
PR Iteration Time — the average calendar hours between the first non-submitter comment on a PR and the submitter's last commit, rounded to the nearest hour. This isolates the "respond and revise" loop from total PR age. PRs with no non-submitter comments are excluded from the average.
Responsiveness — the average calendar hours a submitter takes to respond after a reviewer action, rounded to the nearest hour. A "reviewer action" is any comment, commit, or other contribution by a non-author on the PR timeline, including the merge event itself. Captures how quickly authors come back when feedback lands.
Time to Merge — the average calendar hours between PR creation and merge into the target branch, rounded to one decimal place. The clock starts at creation regardless of whether the PR was opened as a draft. The end-to-end submitter outcome.
How to interpret them
A healthy team has moderate Iterated PRs, short PR Iteration Time, and responsive authors. The combination of all three is what produces a low Time to Merge.
If Time to Merge is high but Responsiveness is good, the slowdown is on the reviewer side. Pair this view with Reviewer metrics.
If Iterated PRs is very high and PR Iteration Time is long, PRs are likely too big — large diffs invite more rounds of revision.
What to do about it
Trim PR size. Submitter metrics improve almost everywhere when PRs are smaller and easier to revise in one pass.
If Responsiveness is low for specific authors, check their workload before coaching — it's usually load, not engagement.
Always pair Submitter and Reviewer metrics. The two together explain most of the review-cycle delay you'll see in Lead Time for Changes.
Related
Reviewer metrics
Team Collaboration Network — overview
Lead Time for Changes