Code churn measures how much code gets rewritten or deleted within a short period after being written, typically within 21 days of the original commit. It is expressed as a percentage of total lines written that are subsequently changed or removed within that window.
High code churn is a signal. It points to rework happening at scale: requirements that changed after coding began, pull requests too large to review cleanly, or design flaws caught late in the review cycle. For engineering leaders tracking delivery metrics, code churn connects directly to wasted sprint capacity and missed delivery targets.
What Is Code Churn?
Code churn in software development is the amount of code added, modified, or deleted that is then changed again within a short window after its initial commit. The standard measurement window, used by GitHub and LinearB, is 21 days from the original commit date.
The formula is straightforward:
Code churn rate = (Lines changed or deleted within 21 days of first commit) / (Total lines written) × 100
A team writing 10,000 lines in a sprint with 3,000 lines subsequently modified or deleted within three weeks has a 30% code churn rate for that period.
Code churn is distinct from planned refactoring, which is deliberate work to improve code structure. Churn refers to unplanned rework: code changed because the first version was wrong, incomplete, or built on requirements that shifted.
Why Code Churn Matters to Engineering Leaders
Every churned line of code represents time spent twice: once to write it and once to rewrite it. In a team writing 20,000 lines per sprint with 30% churn, roughly 6,000 lines are being reworked. That is not a minor inefficiency.
The costs compound in several ways:
Delivery time: Rework extends cycle time. When code written on day one needs significant changes on day twelve, delivery slips. The ticket stays in progress longer and occupies developer attention that could be on new work.
Bug introduction risk: Code changed late in a sprint or after review is written under time pressure. The conditions for introducing new defects are higher on rushed rewrites than on first-pass code.
Cognitive load: Developers returning to code they already wrote spend time re-establishing context before they can make changes. This does not appear in velocity metrics but affects output.
Morale: Writing code that gets rewritten repeatedly is demoralizing. Persistent high churn is a warning sign for team health.
For engineering leaders making the case for delivery improvements to a CTO or CFO, code churn provides a concrete number that translates directly into capacity and cost terms.
Common Causes of High Code Churn
Understanding the cause matters before acting on the metric. The main drivers are:
Unclear or changing requirements: The most common cause. Code written to a specification that changes midway through a sprint will need to be changed. Churn from requirements instability is a planning problem, not a development problem.
Pull requests that are too large: Large pull requests are harder to review thoroughly. Feedback on a 500-line PR often catches issues that require significant rework. Smaller PRs are reviewed more carefully and generate less late-stage churn.
Design issues caught late: When a code review surfaces a design flaw rather than an implementation detail, the fix is often a partial rewrite. Design reviews held before coding begins prevent this category of churn.
Context switching: Developers interrupted by higher-priority tickets who return to in-progress work a week later often find their earlier code no longer fits what they now understand about the requirement. The rework that follows counts as churn.
Technical debt in adjacent code: Making a change in a poorly structured part of the codebase can force unplanned rework on code that was otherwise complete.
How to Measure Code Churn
Code churn can be measured at different levels of granularity, each useful for different purposes.
PR-level churn: Measures the percentage of lines in a pull request that were changed before merge or within 21 days after merge. Useful for identifying pull requests that generated more rework than usual.
Developer-level churn: Tracks each developer's churn rate over a sprint or quarter. Useful for identifying where requirements clarity or PR size is creating patterns of rework. Use with care: individual churn rates should inform coaching conversations, not performance rankings.
Team-level churn: The team's aggregate churn rate over a period. This is the most useful metric for engineering leaders tracking delivery health at squad level.
Repository-level churn: Identifies which parts of the codebase generate the most rework. High churn in a specific service or module often points to technical debt or frequent requirements changes in that area.
Most version control systems (GitHub, GitLab, Bitbucket) log the raw data needed to calculate churn. Engineering analytics platforms surface this automatically.
Code Churn Benchmarks
LinearB benchmark data from thousands of engineering teams provides reference points across performance tiers:
Elite: Under 15% code churn rate
High: 15–25%
Medium: 25–35%
Low: Over 35%
The industry median sits around 25–35%. Teams that actively track and manage code churn tend to operate in the 15–25% range.
Context matters when interpreting these numbers. Teams working in areas of high technical debt, rapid product iteration, or frequent requirement changes will run higher than teams working in stable, well-understood domains. The goal is not to hit an absolute number; it is to understand your baseline and move it in the right direction.
LinearB data also shows that pull request size is one of the strongest predictors of post-merge churn. PRs over 400 changed lines generate substantially more rework than those under 200 lines.
For the broader delivery metrics picture, see our engineering operations guide.
How to Reduce Code Churn
The levers differ depending on the cause, but several interventions apply broadly:
Reduce pull request size. The single strongest lever. PRs under 200 lines generate less rework than large ones. Set a PR size guideline and track adherence. This is about breaking work into smaller units that review cleanly, not restricting what developers build.
Define requirements before coding starts. A 30-minute specification review before a ticket moves to In Progress prevents the most common cause of churn. If requirements routinely change after development begins, the problem is in the planning process, not the development process.
Run design reviews before code reviews. Catching a design flaw in a design review costs nothing. Catching it in a pull request means rewriting already-written code. For complex features, a brief architecture discussion before the first commit eliminates a whole category of churn.
Apply WIP limits. Developers working on one thing at a time produce less churned code than those juggling multiple tickets. Context switching costs re-familiarization time and creates the conditions for rework.
Set a code review SLA. Delayed review forces context switching. When a developer's PR waits four days for review, they have moved on to other work and must re-establish context to address feedback. A first-review SLA of four hours reduces this.
For teams already measuring AI-assisted code review, code churn is one of the metrics where AI review tools show clear impact. See our data on AI code review and engineering team outcomes.
How Scrums.com Tracks Code Churn
Scrums.com is an engineering intelligence platform that tracks code churn alongside DORA metrics, cycle time, and PR health in a single dashboard. It connects to GitHub, GitLab, and your CI/CD pipeline automatically, surfacing code churn at the PR, developer, and team level so engineering leaders can spot rework patterns before they affect delivery. See how it works.
Frequently Asked Questions
What is code churn in software development?
Code churn is the percentage of code that gets rewritten, modified, or deleted within a short period after its original commit, typically within 21 days. It measures unplanned rework: code changed because requirements shifted, the initial design was flawed, or pull requests were too large to review thoroughly.
What is a good code churn rate for an engineering team?
Based on LinearB benchmark data, Elite teams maintain a code churn rate under 15%. High-performing teams typically fall in the 15–25% range. The industry median is 25–35%. Teams above 35% are generating enough rework to affect delivery output and sprint capacity.
What causes high code churn?
The most common causes are unclear or changing requirements, pull requests that are too large for thorough review, design flaws caught late in the review cycle, and context switching that forces developers to re-establish context on in-progress work. Each cause points to a different fix: requirements clarity, PR size guidelines, design reviews before coding, or WIP limits.
How do you measure code churn?
Code churn is calculated as the percentage of lines changed or deleted within 21 days of the original commit, divided by total lines written. It can be measured at the pull request, developer, team, or repository level. Most version control platforms log the raw data; engineering analytics tools surface it automatically.
How does code churn relate to DORA metrics?
Code churn is not one of the four DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to recovery), but it is a leading indicator for several of them. High code churn extends lead time for changes and can increase change failure rate when late-stage rework introduces defects. Teams tracking DORA metrics benefit from adding code churn to understand where in the development process rework is being generated.
