Code churn is a KPI that showcases how often a piece of code is edited.
While churn is normal on any team, as a manager, you may, from time to time, notice it’s unusually high. Don’t ignore it – this could be an indicator someone (or the entire team) is struggling with a specific assignment.
Do you use Git and Jira?
Take them to the Next Level with our Git-Jira integration
→ Try it For Free ←
Code churn could be happening for several reasons that a good manager needs to look out for. For example, it could indicate a lack of skill or knowledge in a particular area. It could also signal poor communication between the team and client or the team (or team member) not understanding the requirements. When there’s a lack of understanding, chances are it’s the code that suffers. Hence, the multiple rewrites or churn.
At What Point Does Churn Become a Problem?
While testing, exploring, and occasionally reworking is typical in a collaborative environment like Git, and ideal churn rates may vary, if you are seeing a 20% churn rate (or more, you likely should investigate.
Remember that churn rates that are unusually high aren’t a problem by themselves. They are signals to certain behaviors that need to be rectified.
These include:
- An engineer’s need for perfectionism
- A misalignment between the engineer and the company’s standards or expectations
- A client’s unclear instructions or ambiguous specs
- A lack of knowledge
Recognizing Churn on Git
High levels of churn will likely happen in the back of a sprint. If you suspect churn, look at Snapshot or Spot Check reports to see if churn rates are climbing higher than your engineer’s historical average.
What to Do When You Notice Churn
Firstly, recognize that churn can be absolutely normal in all kinds of situations. Take a step back and look at the project. If it’s a Proof of Concept (POC), prototype, or redesign, you should expect large rewrites of existing code, and churn may not actually be out of place in these situations.
However, if something appears to be off, do some investigation to see what may be causing the issue.
If it’s an external stakeholder (and you’ve verified this is the case with the engineer), be prepared to show the data that’s causing the issue (for example, last-minute specs or changes that throw the project into disarray). You likely will have to pull the ticket from the sprint and/or arrange a refinement sprint based on the last-minute additions.
If the issue is not an external stakeholder, pinpoint the engineer (or engineers) and pair them with a team lead to coach them through the areas where they are struggling. You can also:
- Ask for pre-submit code
- Split the work to help get to the root cause of the churn
- Seek a senior developer’s insights into what work is good enough in the context of the project
At the end of the day, finding the cause of churn and working to alleviate it will not only strengthen the project it will also strengthen your team members. By catching the problem and dealing with it head-on and with full transparency, you’ll be able to get your churn levels down to an acceptable level while keeping your code in good shape and hitting your sprints.
Get Jira and Git to talk to each other! Download our Git-Jira integration app for an easy way to manage your Git right from Jira. Bitband specializes in Git-Jira plugins (including Bitbucket, GitHub, Gitlab, and more), and you can find them all right on the Atlassian Marketplace.
Want more Bitband insights? Check out:
