Get pull requests through faster with Swarmia's insights and working agreements around cycle time
Cycle time is one of the key metrics to consider in an engineering team. Originally borrowed from lean manufacturing, in software development it serves as a rough measure of development speed, and shows how long it takes for code to complete all stages of the software development pipeline.
Why care about cycle time?
Measuring and improving cycle time means delivering software to end-users faster, shipping in small batches, and reducing the risk of code getting stale. Cycle time is also an important indicator of business success. In their book, Accelerate, the authors of influential yearly DevOps reports have found a direct connection between cycle time and innovation, competitiveness, and organization efficiency.
Lower cycle time means:
Shipping in small batches without interruption
Getting feedback from end users faster
Reducing risk and overhead
Reviewing and merging new code timely
How is pull request cycle time measured in Swarmia?
In Swarmia, pull request cycle time is the total time pull requests spend on all stages of the development pipeline. In practice, it's a sum of three metrics:
Time in progress — from the 1st commit to review request
Time in review — from review request to approval
Time to merge — from approval to merge
In the above metrics, both ongoing and merged pull requests are considered, helping to evaluate the expected closing times for all ongoing pull requests in the pipeline. Thus, if you close pull requests timely, cycle time goes down, and old and stale pull requests open for a long time will cause it to trend up.
What's a good cycle time?
According to the authors of Accelerate, “elite” teams reach a cycle time of less than a day, while high-performing teams deliver code in under 7 days on average.
Use pull request insights to look into cycle time and other pull request metrics in Swarmia.
What contributes to cycle time?
Let's consider the key factors contributing to cycle time, and how you can impact them. Among others, we suggest focusing on the following:
Work in progress queue Working on too many pull requests at once often correlates with longer delivery times. Use Swarmia's WIP working agreement to agree on a target with the team (e.g. up to 10 pull requests open at once) and keep track of it over time.
Time in progress Shorter in progress time means focusing on splitting work into smaller batches that are easy to plan, review and deploy.
Time in review Creating smaller pull requests that are easy to review, using code owners in Github to assign reviewers automatically once a pull request is open are some ways to lower review time.
Pull request size Smaller pull requests are easier to plan, review and deploy.
Time to merge Making approved pull requests a priority, agreeing on merge rituals with the team (Who has the responsibility to drive the pull request forward? Who can merge code?), and investing in production infrastructure helps to reduce waiting time between approval and merge.
Lowering cycle time with Swarmia
Start with a clean-up
If measuring cycle time wasn't ever a priority, there are likely some very old pull requests waiting to be closed. Use Pull Request overview to identify old pull requests and decide what to do with them.
To get a more relevant view of your data, exclude outlier pull requests from all metrics. This lets you focus on lowering cycle time for newly opened pull requests.
You can bulk exclude all pull requests that have been open for a month or longer, or archive individual ones. We recommend starting with the bulk exclusion, as you can include any excluded pull requests back into metrics later.
Adopt a working agreement
Once you've identified cycle time as an improvement area, look at the Pull Request insights together with the team:
Decide what a realistic maximum target is (7 to 14 days is a good starting point).
Adopt a pull request max age working agreement and set it to what you just decided.