Engineering Velocity: How to Measure It and Why It Stalls

Most engineering velocity conversations are arguments about story points. They should be arguments about cycle time. Founders ask whether the team is shipping faster and engineering replies with “our velocity is 47,” which answers no useful question. This is the conversation we run with every client whose CTO has just told them the team has slowed down.

What is engineering velocity, actually

The phrase has been corrupted by Scrum vocabulary. Velocity in software development used to mean a useful thing: the rate at which a team converts decisions into running production code. Now it usually means the sum of story-point estimates closed last sprint, which is a measurement of estimation accuracy, not throughput.

A serviceable definition: engineering velocity is the time from a decision to ship something to that thing running in production for real users. Measured in days, not points. It covers design, code, review, deploy, verification. It excludes planning and research, because those are different activities with their own rhythms.

Most teams searching for what is engineering velocity, velocity software development, or what is velocity in software development are really asking one of these:

• Are we slowing down compared to last quarter?
• Are we slow compared to other teams at our stage?
• Why does it feel slower even though we are hiring?

The first two are measurable. The third is usually the most interesting question in the room.

The engineering velocity metrics that earn their place

The most useful engineering velocity metrics are the four DORA metrics, but most teams measure them in the wrong order:

Metric	What it measures	Type
Cycle time	Hours from first commit to merge	Leading
Deploy frequency	Deploys per day per service	Leading
Lead time for change	Days from PR open to production	Lagging
Change failure rate	% of deploys that cause an incident	Lagging

Cycle time and deploy frequency are the levers. Lead time and change failure rate are what improves when you pull those levers. Teams that fixate on the lagging numbers watch them move slowly and get demoralised. Teams that fix the leading numbers see the lagging ones follow within a month.

What we do not measure: story points completed, velocity per sprint, lines of code, PR count. Each is a proxy for activity rather than throughput, and each is gameable in obvious ways.

A diagnostic for stalled velocity in software development

When velocity in software development stalls, the cause is almost always one of these, roughly in order of frequency:

1. Review queue depth. PRs wait more than 12 hours for review. The fix is a written review SLA (target: 2 working hours), not more reviewers.
2. Environment flakiness. CI fails non-deterministically. Staging is unreliable. Deploys need a Slack handover. Trust the build before you trust the team.
3. On-call load. Incidents and pages eat senior engineering time. If on-call burns 20% of capacity, you do not have a velocity problem; you have a reliability problem wearing a velocity costume.
4. Scope creep mid-sprint. Whatever you committed to is no longer the work being done. Cycle time inflates while throughput stays flat.
5. Hiring debt. New engineers, even strong ones, slow the team for two months. Velocity dips proportional to onboarding load.

Each cause has a different fix. Treating “velocity is down” as a single problem produces the same bad outcome every time: a process change that does not match the underlying cause.

A worked example: from 4-day to 14-day cycle time

A Series A team we worked with measured a four-fold increase in cycle time over six months. The team had grown from six to fourteen engineers. Velocity, by their internal definition, had also grown by 4x. Throughput had not.

The diagnosis took a week:

Cycle time: 14 days
   ├─ PR review wait time:   4.2 days  ← biggest single contributor
   ├─ CI flakiness retries:  2.1 days
   ├─ Manual deploy gating:  1.8 days
   └─ Real coding + review:  5.9 days

The fixes were unglamorous. A four-hour review SLA. A two-week investment in CI stability. One engineer-week to remove the manual deploy step for the three services that still needed it. Cycle time dropped to five days within a month, with no headcount change and no new tools.

How to talk to the board about software development velocity

Boards do not want a software development velocity dashboard. They want one sentence per quarter that says whether engineering is delivering against the business plan. That sentence is usually built from three numbers: cycle time, change failure rate, and a count of “shipped vs committed” features.

If those three are stable or improving, velocity is fine. If two slide in the same quarter, something is wrong, and the team should know what before the next board meeting.

Avoid presenting story points to boards. Points are an internal estimation tool. Showing them externally invites comparisons against teams who measure differently and undermines whatever credibility the numbers have.