Iterated PRs

Iterated PRs is the percentage of merged pull requests with at least one follow-on commit. These PRs have been iterated on by your team.

Which reports use Iterated PRs?

See Iterated PRs in reports like Team health insights, Review collaboration, and Check-in.

What does Iterated PRs measure?

Iterated PRs helps you see how many of your team’s submitted pull requests require additional work before being merged.

Iterated PRs is a Goldilocks number: you don't want it to be too high or too low. In general, having more iterated PRs is evidence that you have good collaboration on your team. If you have too many iterated PRs, it's evidence that you're introducing collaboration too early in your process and that the initial PR is lacking in quality or is not aligned with requirements. If you have almost no iterated PRs, it means no one is changing their code after a review, which usually means reviews aren't happening or are being ignored when they do.

Identify a good range of Iterated PRs values for your team and keep an eye on this number as you drive to maintain a good balance of collaboration.

How is Iterated PRs calculated?

Iterated PRs is calculated as the total number of merged pull requests with a follow-on commit divided by the total number of merged pull requests.

The follow-on commit can be made by either the pull request submitter or a reviewer.

What data is included in Iterated PRs?

A pull request counts toward Iterated PRs if it is a merged pull request.

Commits on a PR are counted as follow-on commits unless they are:

• created by a user who is excluded from metrics

• created by a hidden user

• excluded manually or through outlier detection

• merge commits

Pull requests are not counted toward Iterated PRs if they are:

• created by a user who is excluded from metrics

• created by a hidden user

• an excluded pull request

• from a deleted repository