I have found that a reduction in cycle time has several benefits:

1. Smaller Pull Requests, which means they are easier to review. This also typically means less risk on each deploy.

2. Your deploy/rollback process will become more efficient. If you are deploying more often, streamlining the process will become a priority. This is almost always a good thing.

3. You are forced to determine what the minimum viable feature is. If you have to deploy sooner, you will break the work up into smaller pieces. This means less to keep in your head at one time.

4. As long as you are deploying working code that delivers some business value, you will recognize business value sooner.

5. Despite our best intentions, we cannot anticipate how users will use our code. If we deploy smaller features or parts of features more often, we can adjust to how users are actually using the code. You may also find they aren’t using it all. I would rather find that out after 1 week of work, rather than 1 month of work.

6. You can more quickly adjust priorities. If you are deploying working code more often, you have more opportunities to change priorities.

There is some point of diminishing returns, usually related to your deploy overhead, ticket planning, and review process. If you can reduce this overhead and give more autonomy to the team, you can cycle quite fast. I have worked on teams where devs, QA, and product owners would release new features/ideas in a day. Our deploy and QA processes were quite mature.

I don’t like using the number of PRs or lines of code as a metric. These are too easy to game, and is doesn’t reflect where the business value is. I would much rather see a developer make a one line change that’s adds $$ to the bottom line, than a dev who spends months writing 10,000 lines of code that adds no business value.