What is engineering velocity?

Engineering velocity is how quickly a team turns ideas into shipped, working software, without sacrificing quality. It is measured by delivery metrics over time, not by lines of code or hours worked.

What velocity is and is not

Velocity measures the flow of finished work, not the activity that produces it. A team that ships small, working changes often has high velocity, even if it writes less code than a team that produces large, unreviewed batches.

• It is: the rate of shipping working software over time.
• It is not: lines of code, commits, or hours worked.
• It is not: a per-person productivity score.

How to measure it

Useful measures track delivery, not effort. The DORA metrics are a common starting point.

• Deployment frequency: how often the team ships to production.
• Lead time for changes: how long a change takes from commit to production.
• Change failure rate: how often a release causes a problem.
• Time to restore: how quickly the team recovers from a failure.

Cycle time, the span from starting work to merging it, is a close companion and often the first thing teams track.

What slows it down

Velocity drops when finished work waits or has to be redone.

• Review bottleneck: changes pile up waiting for a reviewer.
• Rework: defects found late send work back to the start.
• Flaky or slow pipelines: tests that fail at random or run long.

Past shortcuts add up too: technical debt makes each new change slower than the last.

How to raise it sustainably

The goal is steady flow, not a short burst that creates cleanup later.

Ship smaller changes, which are faster to review and safer to release. Automate testing and delivery with CI/CD so releases are routine, and protect code quality, since rework is the most expensive drag on velocity. Continuous delivery keeps the path to production short, so finished work does not wait.