Diagnosing low pull request throughput

Throughput is a bit more difficult to improve than for example cycle time, since it reflects the team's overall situation rather than just the process.

Here's some topics a team could discuss regarding pull request throughput:

1. Are we using pull requests for everything? If we have a habit of pushing changes directly to the main branch, the pull request metrics are less accurate.
2. How large are the pull requests? The optimal size depends on the programming language and many other factors, but generally it's good to change fewer than a few hundred lines of code at once.
   1. What's your branching strategy? Are you targeting short-lived branches?
   2. Do you have the infrastructure for example for feature gates? It allows you to keep features hidden even if the code has already landed in the main branch.
3. Are we working on some other tasks? Multi-tasking takes a toll on development work.
4. How much time are we spending in meetings? How are they spread throughout the day?
5. How familiar are we with the codebase?
   1. If I need to touch a product area I'm not familiar with, how easy is it to find someone who knows about it?
   2. Are we actively spreading the knowledge about the codebase by working together on each feature?
6. How easy is it to write automated tests?
   1. Are we testing at the right level? How does our testing pyramid look like?
   2. Do we have all the required helpers to make it easy? For example, how easy is it to generate test data for an integration test?

Swarmia helps you diagnose these things in Work Log and Insights.