In the book you can check the sections Avoid Burnout: Work Overload and Overload Risk: Too Much Concurrent Work.
We get 6 months weekly average pull request throughput of each team. We call this the "Baseline Throghput". If a team has more (or less in some cases) pull requests open than the baseline, we consider that a "too many".
Too many Open Pull Requests can signal taking on too much work, scope creep, change in priorities and unexpected issues/bugs coming into the sprint. It’s good to keep an eye out of the number of Open Pull Requests since it’s a great indicator of the team’s current workload.
Comments
Very curious now: how do you know what is "too much" time in code review?
Could you provide an example of actionable insight you provide when you have detected that a team is taking on too much concurrent work?
In the book you can check the sections Avoid Burnout: Work Overload and Overload Risk: Too Much Concurrent Work.
We get 6 months weekly average pull request throughput of each team. We call this the "Baseline Throghput". If a team has more (or less in some cases) pull requests open than the baseline, we consider that a "too many".
Too many Open Pull Requests can signal taking on too much work, scope creep, change in priorities and unexpected issues/bugs coming into the sprint. It’s good to keep an eye out of the number of Open Pull Requests since it’s a great indicator of the team’s current workload.
Absolutely agreed. None of that is particularly actionable, though. "Don't do the bad thing" is not actionable advice!