Agile Coding Productivity: LOC CSV Exports vs Story Points

Export your LOC CSV the night before sprint review — not the morning of

Run your multi-language LOC counter against the main branch at 11 PM on the last day of the sprint. That gives you a clean snapshot after the final merge window closes but before the next sprint's first commit lands. I learned this the hard way: a Tuesday-morning export once included three commits that belonged to the next sprint, and my productivity chart showed a 22% spike that didn't actually exist. The retrospective conversation went sideways before anyone realized the data was stale.

Here's the thing though. Most teams I work with are running polyglot microservices — a Go auth service, a Python data pipeline, some TypeScript frontend, maybe a Rust sidecar. Measuring agile coding productivity across that stack is genuinely hard. You have two paths. Path A: rely on story points and gut-feeling sprint reviews, where a senior dev says "felt like a heavy sprint" and everyone nods. Path B: export structured LOC data per language per sprint and let the numbers challenge your assumptions. I'm going to walk you through Path B — specifically, how to use multi-language LOC counter CSV exports to build a productivity signal that actually survives scrutiny.

Normalize multi-language CSV rows into one comparable signal

Your LOC counter spits out rows like this: language, files, blank_lines, comment_lines, code_lines, repo_path. A typical sprint export across a polyglot repo might give you 8-12 language rows. Go: 4,200 code lines. Python: 2,800. TypeScript: 6,100. Shell scripts: 340. YAML configs: 1,900.

The mistake I see constantly — and I made it for a year — is summing all code lines into one number and calling it "sprint output." That's misleading because 1,900 lines of YAML are not the same engineering effort as 1,900 lines of Go. Here's what I do instead.

Weight by language complexity, not by raw count

I assign a rough effort multiplier per language in a second CSV column: Go 1.3, Rust 1.5, Python 1.0, TypeScript 0.9, YAML 0.2, Shell 0.4, SQL 0.6. These aren't scientific. They're calibrated from six months of comparing LOC deltas against actual story points delivered. Multiply code_lines by the weight, sum the results, and you get a normalized productivity unit that's far more honest than raw LOC.

Last sprint, my raw total was 14,340 code lines. Weighted total was 11,820. The difference came mostly from 3,800 lines of generated OpenAPI YAML that the counter picked up but contributed almost no engineering effort. Without normalization, that sprint would have looked like our most productive ever. With it, the number sat right in our rolling average.

Track net LOC, not gross LOC — refactoring is invisible otherwise

This is where Path A and Path B diverge most sharply. In a gut-feeling sprint review, someone who spent four days deleting dead code and simplifying a module looks like they "didn't ship much." That's broken. But a naive LOC counter that only measures added lines makes the same mistake.

Configure your LOC counter to export both added_lines and removed_lines per language. Then compute: net_loc = added_lines - removed_lines and churn = added_lines + removed_lines.

Why churn matters more than net for agile teams

Net LOC tells you whether the codebase grew. Churn tells you how much engineering activity happened. A sprint where you deleted 2,000 lines of legacy Python and added 300 lines of clean replacements has a net of -1,700. By raw LOC, that's negative productivity. By churn, it's 2,300 — a seriously active sprint.

I report both numbers in every retrospective. Net LOC shows whether we're accumulating technical debt or paying it down. Churn shows whether the team was actually engineering. Last quarter, we had a sprint with +180 net LOC but 4,600 churn. That was a massive refactoring sprint on the auth service. Path A would have called it a light sprint. The CSV data told the real story.

Cross-reference LOC deltas with commit message tags in your export

Your git log already has structured data if your team uses conventional commits — feat:, fix:, refactor:, chore:, docs:. The problem is that most LOC counters don't join their output to commit metadata. You get file-level counts with no semantic context.

Here's the workaround I use. After exporting the LOC CSV, I run a second script that pulls commit-level data: commit_hash, author, message_prefix, files_changed, insertions, deletions, language. Then I join the two on file path and language. Now I can break sprint productivity down by intent.

The breakdown that changes retrospective conversations

Typical joined output from a recent sprint:

• feat: — 6,200 inserted, 1,100 deleted (new functionality)
• refactor: — 2,400 inserted, 5,800 deleted (paying down debt)
• fix: — 890 inserted, 1,200 deleted (bug fixes)
• chore: — 340 inserted, 90 deleted (dependency bumps, config)
• docs: — 1,100 inserted, 200 deleted (documentation)

Total churn: 19,320 lines across 47 commits. Feature work was 32% of churn. Refactoring was 42%. In a Path A review, the team would have said "we shipped the auth refactor and a couple features." The CSV data revealed that refactoring dominated the sprint — which prompted an honest conversation about whether we'd under-invested in new feature delivery.

Build a rolling 3-sprint baseline instead of judging one sprint

Single-sprint LOC data is noisy. Someone takes a week off. A spike investigation produces zero merged code. A vendor integration dumps 4,000 lines of generated SDK into the repo. If you judge productivity sprint-by-sprint, you're reacting to variance, not signal.

I maintain a rolling three-sprint weighted average in a simple CSV that appends each sprint's export. The formula: rolling_avg = (sprint_n + sprint_n-1 + sprint_n-2) / 3. If a sprint's normalized productivity falls below 60% of the rolling average, that's a flag — not a verdict. Something worth discussing. Above 140%? Also a flag. Did we cut corners? Did generated code inflate the count?

Our rolling average over the last three sprints sits at 11,400 weighted LOC. Sprint 14 came in at 7,200 — well below the 60% threshold of 6,840. Turned out two senior engineers were on PTO and the team spent the sprint on a difficult debugging investigation that produced a 40-line fix but consumed the entire sprint. The CSV data gave us a way to talk about that objectively instead of pretending it didn't happen or blaming the team.

Filter generated and vendored code out of your CSV before analysis

This is the single biggest source of false productivity signals in polyglot repos. Your LOC counter doesn't know the difference between hand-written Go and a vendored protobuf library. It counts everything.

Before you do any analysis, filter your CSV export. I maintain a blocklist of paths that get stripped out: vendor/, node_modules/, *.pb.go, dist/, build/, __generated__/, openapi.yaml (when auto-generated), package-lock.json, go.sum. After filtering, my typical sprint export drops from 18,000-22,000 raw lines to 8,000-14,000 actual engineered lines.

Document your filter rules in the repo

Put your filter configuration in a file like .locfilter at the repo root. Commit it. Review it when onboarding new services. If someone adds a new generated-code directory and doesn't update the filter, your productivity data silently breaks. I audit the filter list every quarter by comparing filtered vs unfiltered totals — if the gap suddenly shrinks, something generated is slipping through.

Use LOC trends to challenge sprint commitments — never to rank developers

This is the line I won't cross. LOC data is useful for understanding team-level productivity patterns. It is toxic when applied to individuals. A developer who writes 200 lines of elegant, tested, documented code is not less productive than one who dumps 2,000 lines of fragile spaghetti. The CSV can't tell the difference. Don't pretend it can.

Where LOC exports genuinely help is in sprint planning. If your rolling average is 11,400 weighted LOC and your next sprint has 18,000 LOC of planned feature work across the committed stories, that's a data-driven signal you're overcommitting. Path A — gut-feeling planning — would have the team say "yeah, we can probably do it." Path B gives you a concrete number to push back with.

I bring the rolling average and the planned-work estimate to every sprint planning session. Not as a hard cap — as a reference point. When the team commits to 16,000 weighted LOC against an 11,400 average, I ask: "What's different about this sprint?" Sometimes there's a good answer — a new hire, a cleared backlog, a focused two-week push. Sometimes there isn't. The LOC data creates the conversation. That's its job.

Measuring agile coding productivity with multi-language LOC CSV exports isn't about building a leaderboard. It's about replacing "felt like a big sprint" with a number you can interrogate. Export consistently. Normalize across languages. Track churn alongside net. Filter generated code. Build a rolling baseline. Then use the data to ask better questions — not to deliver verdicts.