The metrics we’ve included in the Velocity application are designed to align the incentives of managers and their reports-- so, for the most part, when metrics are “gamed,” your team is improving how they work.
There are two ways in which we achieve this:
Work-centric metrics: Agile software development is, by nature, a collaborative practice, so many of the metrics we track are collaborative work artifacts. Metrics like Review Cycle Time, or PRs merged ensure that developers keep each other accountable, and the quality of work isn’t compromised for speed (and vice versa).
Complementary metric sets: No one metric is the end-all-be-all of engineering productivity, so we equip engineering managers with a handful of metrics that create a healthy balance of priorities. This ensures that there’s no over-optimizing for one metric to the detriment of another.
Take a look at more specific examples below.
Work-Centric Metrics
Take a look at how gaming some of our core metrics will instill better work habits:
Pull Requests Merged: This metric counts the total number of pull requests merged per day over a given period. If a developer tries to game this metric, they’ll break their work in smaller segments, making the code easier to review and easier to maintain in the long term. Read more about this metric here.
Time to Merge: This metric reports the average length of time between opening a PR and merging it. Gaming this metric means pushing clear, easy-to-review code. This practice ensures that the developer’s code up to standards, and they’re striving to work well with their peers. Read more about this metric here.
Review Speed: This metric shows the time between when a pull request is opened and when the reviewer first submits feedback. Gaming this metric ensures a healthy balance of pushing your own code and lending a hand to your co-workers.
Rework: This metric shows how much of their own code an individual contributor edits within three weeks after pushing. Gaming this metric (keeping this number low) means developers have to take a proactive approach to keeping their code maintainable. Read more about this metric here.
When Velocity metrics are “gamed,” successful work habits are instilled, thereby improving the quality of your code and the speed of your engineering team.
Complementary Metric Sets
Within Velocity, you have access to Radar charts that plot each metric according to the industry standard. The grey circle represents how this team member has performed in the prior 30-day period, while the blue circle represents how the team members has performed this 30-day period.
At a glance, you can see any irregular work patterns or how a focus on one metric has affected others. For instance:
Pushes per Day vs. Rework: You might find that more pushes result in a lack of quality, increasing the amount of rework an engineer must do.
Coding Days vs. Throughput: You might find that an increase in coding days is to the detriment of throughput, signifying burnout or lack of productivity after a certain point.
PRs Reviewed vs. Pushes per Day: You might find that individuals are so caught up helping their peers, they don’t have time for their own work.
Focusing on a handful of metrics will result in a healthy balance of priorities:
While we’re constantly working to optimize and design metrics that are difficult to game, part of the work lays on the team implementing Velocity.
Teams that use metrics as a starting point or as supplementary to conversations don’t typically find that their engineers try to “game” these kinds of metrics. It’s only when metrics are trusted blindly and frequently cause punitive action that we hear of engineers trying to over-optimize for one metric or another.