How to measure agile coding productivity using multi-language LOC counters and CSV file analysis

Quick tip: export your LOC counts to CSV before you even think about "productivity"

Here's the move that saves you hours of awkward sprint review meetings: run a multi-language LOC counter that outputs straight to CSV, then sort the delta column. If you're a team lead trying to explain why Sprint 14 "felt slow" despite 38 story points marked complete, the raw numbers in a spreadsheet will either back up your gut feeling or quietly correct it. Let's walk through exactly how to do this using a real example — Team Atlas, a six-engineer squad working across Python, TypeScript, and Go in a polyglot microservices codebase.

Lock down your language scope before counting a single line

Before you run any counter, define what you're actually measuring. "Multi-language" sounds impressive on a tool's feature page, but if your LOC counter picks up .json configs, .md docs, and vendored dependencies, your productivity numbers are already broken.

What to include

For Team Atlas, we count only hand-written source files:

• Python: *.py — excluding Alembic migrations and __pycache__
• TypeScript: *.ts and *.tsx — excluding auto-generated OpenAPI types
• Go: *.go — excluding the vendor/ directory

What to exclude

Hard-block these in your counter config so they never touch your CSV:

• Anything under node_modules/, vendor/, dist/, or build/
• Auto-generated files — protobuf stubs, ORM migrations, codegen output
• Test fixtures and mock data JSON

This gives you a clean denominator. At the start of Sprint 14, Team Atlas had 142,300 lines across these three languages combined. That number becomes our baseline — the thing we measure against at sprint close.

Pick a counter that speaks CSV natively

Plenty of LOC tools can count lines across languages. Far fewer can dump results into a structured CSV without you writing a wrapper script. You want a tool where the output looks something like this out of the box:

language,file_path,blank_lines,comment_lines,code_lines,total_lines

For Team Atlas, we use cloc with the --csv flag plus a small --by-file argument. That combination produces one row per source file, per language. When Sprint 14 started, the raw export contained 1,847 rows — one for every Python, TypeScript, and Go file in the repo. Save that file as sprint14_start.csv and move on.

The reason CSV matters over JSON or a pretty terminal table is simple: you're going to diff this against another CSV at sprint end. Spreadsheets, awk, pandas — they all eat CSV for breakfast. You want your code metrics in the format that's cheapest to analyze.

Run the count on the same commit hash every sprint

This is the step where most people introduce noise without realizing it. If you count LOC at 9 AM Monday at the start of a sprint, then count again at 5 PM Friday two weeks later, you're comparing two different states of the codebase — but which states, exactly? If someone merged a hotfix branch in between, your delta includes work that wasn't part of the sprint plan.

The fix: pin your counts to specific commit hashes. For Team Atlas, Sprint 14 started at commit a3f7b21 and ended at ee4c9d0. We check out each commit, run the counter, and export. Nothing ambiguous.

At a3f7b21: 142,300 total code lines.
At ee4c9d0: 145,200 total code lines.
Sprint 14 delta: +2,900 lines.

That 2,900-line delta is now the number we carry into analysis. Not story points. Not "tickets closed." Actual code produced.

Normalize the CSV into a sprint-level snapshot

Once you have sprint14_start.csv and sprint14_end.csv, the fun begins. Load both into your tool of choice — Python with pandas, a Google Sheet, even plain diff if you're feeling rustic — and compute the per-file delta.

Here's what the normalized snapshot for Team Atlas looked like after grouping by language:

Right away, something jumps out: Python accounts for 77% of the code delta but only 68% of the files changed. That means Python files grew larger on average than TypeScript or Go files during this sprint. Is that because the Python service had heavier business logic work? Or because someone wrote a 600-line god class? The CSV gives you the question — you still need to answer it.

Cross-reference LOC deltas with story points

LOC alone doesn't measure productivity. A developer who deletes 200 lines of dead code and replaces them with 50 clean ones just made the codebase better — but your counter shows -150. If you're tracking agile coding productivity, you need to layer story points on top of the CSV data.

For Team Atlas, Sprint 14 closed 38 story points. Here's how that breaks down against the LOC delta:

• Python work (22 SP): +2,250 LOC → ~102 lines per story point
• TypeScript work (11 SP): +500 LOC → ~45 lines per story point
• Go work (5 SP): +150 LOC → ~30 lines per story point

Those ratios are wildly different, and that's the point. Go story points produce fewer lines because Go is verbose-but-compact — you write less to accomplish the same logic. TypeScript story points sit in the middle. Python story points inflate because the language is dense with boilerplate like imports, data classes, and type hints.

If you ever catch yourself comparing raw LOC across languages to judge engineer output, stop. Compare within the same language, across sprints. That's where the signal lives.

Flag the outliers that LOC alone can't explain

Sort your CSV delta column descending. The top five files by LOC growth in Sprint 14 for Team Atlas were:

1. services/billing/invoice_engine.py — +612 lines
2. services/billing/tax_calculator.py — +418 lines
3. web/components/CheckoutFlow.tsx — +287 lines
4. services/billing/invoice_engine.py tests — +244 lines
5. services/gateway/router.go — +96 lines

Four of the top five files are billing-related. That tracks — Sprint 14's theme was "invoice refactor." But notice file #4: the test file grew by 244 lines while the source grew by 612. That's a 2.5:1 ratio of source-to-test code. For healthy Python, you'd expect closer to 1:1 or even 1:2 (more test code than source). This tells you testing lagged behind implementation during the sprint — a productivity quality issue that pure story point tracking would never surface.

Also flag any file with a large negative delta. Team Atlas deleted 340 lines from services/billing/legacy_pdf_gen.py — a dead module finally cleaned up. That deletion is productivity too, even though it shows as negative LOC.

Build a rolling 6-sprint trend line

A single sprint's LOC data is a snapshot. Six sprints of CSV exports stitched together is a trend — and trends are what actually inform decisions about hiring, technical debt allocation, and sprint planning.

Here's Team Atlas's rolling LOC delta across the last six sprints:

Two things pop from this trend. First, Sprint 12 went negative — the infra migration deleted more than it added, which is expected and healthy. Second, the LOC-per-story-point ratio hovers between 62 and 83 for feature sprints. Sprint 14's ratio of 76 sits comfortably in that range, which tells you the team's coding velocity is stable even though the sprint "felt slow."

The feeling was probably caused by context-switching — 50 files changed across three languages is a lot of mental juggling for six engineers. The CSV doesn't capture cognitive load, but it gives you the file-change count that hints at it.

Keep the workflow repeatable

The entire process above — scope definition, commit pinning, CSV export, delta normalization, story point cross-reference, outlier flagging, and trend tracking — should take you under 30 minutes per sprint once it's set up. The payoff is a productivity conversation grounded in actual code output rather than Jira feelings. Bookmark this checklist, run it at the end of your next sprint, and compare the results to what your standup intuition told you. The gaps between data and gut are where the most interesting engineering conversations happen.