# PR Size

{% hint style="warning" %}
Note: this metric is **only shown at a team level**, not an individual level.
{% endhint %}

![A stylized line graph shows time to merge is high at 18 hours but is trending up.](https://cdn.prod.website-files.com/610c8a14b4df1ae46b1a13a3/634800ebfff45604484ae35d_PR%20Size.jpg)

***‍*****What it is:** How large your team's PRs are. We show two representations of this — `Lines Changed` and `Files Changed`.

**Why it matters:** This is another possible bottleneck for `Change Lead Time`. We know that large PRs are harder to review, test, and manage in general. It is now generally accepted that keeping PR size down is best practice for faster reviews, less merge conflicts (and therefore easier collaboration), and simpler rollbacks if required. Learn more in [this 2017 paper by Microsoft and the University of Victoria](http://chisel.cs.uvic.ca/pubs/macleod-IEEESoftware2017.pdf), and in [Google’s own internal guidelines](https://google.github.io/eng-practices/review/developer/small-cls.html) (they say “changelist” rather than “pull request”).**‍**

**How we calculate it:**  We show the **median of the lines of code or the number of files changed per PR** depending on the option selected. We chose to provide 2 options here (instead of just lines of code) so you can get a more well-rounded view of the overall size. We recognise that these are both simple measures of "PR Size" which don't take into account edge cases such as lock files or automated formatters (examples where PR size may be large, but the PR is still easy to review and manage). However, in the majority of cases, the number of lines or files changed is a reasonable indicator of how long a PR may take to get merged.

{% hint style="success" %}
**What good looks like**

Many organizations like to enforce maximum limits on the lines of code (LOC) changed per PR, generally ranging from around 200 to 400. [This study](https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/) also found that PRs should be limited to 200-400 LOC; beyond that, the ability to effectively capture defects goes down. So we recommend keeping LOC under 300 as a good middle ground.
{% endhint %}

{% hint style="warning" %}
Note: `Files Changed` varies - you can have a small number of LOC changed across many files, and it'd still be fairly easy to review. In our teams, we try to keep it under 10 files changed.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.multitudes.com/metrics-and-definitions/process-metrics/flow-of-work/pr-size.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.