I have something like a love for metrics, leadership, teams, people, and success. If you dig into a combination of these topics, an overarching theme jumps out.
The best leaders are using data to put their teams and people in a position for optimal success. Leaders that do not use data are falling behind. This concept holds true for software leaders responsible for teams. Which is why it is important to now be aware of Time to merge (TTM).
Time to merge is a critical metric for measuring software team productivity. It is sneaky sharp, super useful, and a must-know metric for all software leaders.
What is Time to Merge and How to Measure it?
Time to merge measures the amount of time from pull request open until pull request merge. At Linear B, we find it to be useful when calculated as an average at the org, team, and iteration levels with trending over time.
Linear B tracks Time to Merge Automatically and Enables you to Track over Time
Why is Time to Merge a Critical Metric?
TTM is a productivity indicator that encompasses multiple behaviors of a software team including methodology, efficiency, teamwork, quality, value delivery, and culture. Similar to WAR in baseball, it is a rare single metric that touches many productivity aspects. TTM is not a “soft” metric. It’s concrete, tangible, hardly debatable, and straightforward to measure.
What Does Your TTM Say About Your Software Team?
At Linear B, we work with a diverse set of software teams following differing methodologies and team practices. What we have found is this, like a G.I. Joe, knowing is half the battle!
Side note: Dev candidates would ask me questions like, “What dev methodology do your teams use? Agile?”. While this question has the right intention, it is outdated. A better question for your prospective manager, “what is your team’s average time to merge?” Blank stare = danger zone. “Let me show you” = good sign.
Starting with just measuring and tracking your TTM (with trending) is important in determining if your team’s actual behavior aligns with your optimal desired behavior.
Check out these three common scenarios we see from the Linear B community:
1) “Our time to merge is “longer” than expected. We want to improve our throughput!”
- Many teams have never measured their delivery pipeline. Starting with TTM is perfect.
- TTM is discovered as a bottleneck and improvement can now begin.
- The next metric to inspect is time to first action (TTFA), oftentimes this is the culprit.
Time to First Action: A quick start often improves Time to Merge
2) “Our time to merge is “long” but expected. We like it that way!”
- Some teams expect to have longer than average TTM.
- They emphasize “early” PR creation.
- Now that their TTM is known, they are able to measure iteration to iteration to maintain their expected behavior.
- In this methodology, it is still important to have a “short” time to first action!
3) Our time to merge is “short”, maybe too short? We want to improve our quality!
- This type of team has a very efficient PR process but needs to balance with quality.
- We recommend focusing on a few quality metrics like review depth, story to bug ratio, and bugs found in production.
- We also recommend keeping an eye out for “Lightning PRs”, which alert when PRs are merged extremely fast without proper review depth.
Seeing Merged PRs in one view with Bugs, Stories, and Tasks per iteration helps understand quality
A Piece to the Value Delivery Pipeline
Although TTM is critical to measure, it is a piece to the puzzle that makes up your value delivery pipeline. Time to Value is also a metric I like that describes the time from value inception (idea) to the first value delivery (to a customer). I’ll save that for another post but keep this in mind.
We have seen that measuring time to merge is important for all software leaders and teams. Start measuring, feel like Obi-Wan, and empower your team!
Want to measure your team’s TTM? We can help. The Linear B platform makes TTM and other critical metrics easily accessible. Request a trial now!
