This question comes up quite a bit, and the answer is please do!
Let's take a look at what gaming the numbers on a few key metrics might look like:
Unreviewed PRs: Unreviewed PRs is the percentage of merged pull requests that did not receive comment from the team. We want to establish a healthy review cadence to ensure that unnecessary risk is not introduced into the code base. A focus on this metric also encourages knowledge sharing. Engineering organizations have world class minds who can aid in growth and career development. Gaming this metric ensures we are catching bugs ahead of production, while making the team stronger along the way.
New Work percentage: If you're a senior engineer, chances are you have higher than normal Legacy Refactor in your statistics. This is awesome, but it will naturally cause lower New Work ratios. The best thing to do here is pick your favorite junior engineer and help them get into the maintenance business with you: stop taking on all the risky work and spread the load. By doing this, you'll be able to take on more New Work, which will re-balance your work trend numbers and ensure that new features contain healthy patterns for others to follow. This reduces the amount of “other” work for the whole team, not just you.
Coding Days: This one is easy — just push your work every day. No need to merge into a particular branch, since Flow will see anything you add to the repo. This is a good practice, since it increases visibility and makes sure your work is saved somewhere other than your local machine in the event of a hard drive crash.
Time to first comment: This metric encourages you to grab PR’s in a timely manner. Eliminating costly wait states is primarily a courtesy to your peers. Delayed PR review either creates a blocker for individuals on the team, or results in task switching which is arduous and inherently error prone.
Churn: The most reliable way to game the Churn metric is to be methodical about incorporating any recurring feedback from your code reviews. Before checking in a commit, give your code a once-over and make sure you've handled anything that commonly comes up in your pull requests. Focusing on clean PRs is a great way to reduce Churn: pre-PR edits will nearly always show up as Churn in the reports.
Time to merge: Time, in hours, it takes a pull request to be merged. Unresolved PRs are costly to the business, and long running back-and-forth discourse has a tendency to become unhealthy. Establishing resolution targets helps to verify our work is not done in vain. Attention placed on Time to merge results in a decrease to delayed releases.
So, can you game the system?
Absolutely. The point is to "game" the system.
Consistently maintaining "good marks" in Flow, gives you a way to show, not tell, that the team is focused on the right areas and delivering meaningful solutions in the most efficient way possible. Ultimately it offers a path to reducing the miscommunication and political overhead that comes from working on things that are invisible to the rest of the business.
If you need help, please email email@example.com for 24/7 assistance.