# Dev Team Velocity: How to Actually Measure It (and Why AI Won't Double It)

> Source: https://extradev.fr/en/blog/dev-team-velocity-how-to-actually-measure-it-and-why-ai-wont-double-it
> Published: 2026-06-13
> Author: Vincent Roye
> Site: Extra Dev (https://extradev.fr)
> Lang: en-US
> Tags: vélocité, DORA, SPACE, productivité dev, métriques agile, IA développement, story points, throughput

Story points, DORA, SPACE: which metrics actually measure a dev team's velocity? Field data shows AI doesn't double delivery, it shifts the bottlenecks.

Your team finishes its sprints, story points climb, the backlog shrinks. And yet shipping to production stalls, bugs keep surfacing, and time-to-market won't budge. **The problem isn't how fast the code gets written, it's what you're measuring.**

I've seen teams post 80 points a sprint and ship one usable feature a quarter. I've seen others at 30 points push out an MVP in three weeks. The difference comes down to the metrics driving the decisions, not the developers' talent.

- 📊 **DORA, not story points**: four Google metrics measure real delivery, not busywork.
- ⚠️ **AI: -19% in reality**: the METR study shows an observed drop in productivity despite the positive gut feeling.
- 🎯 **Throughput > velocity**: the rate of items shipped to production beats effort points every time.
- 🏗️ **Frame before you accelerate**: clear specs and systematic review turn AI into a real lever.

## What velocity measures (and what it doesn't)

Agile velocity, in the Scrum sense, is the sum of the effort points for items finished by the end of a sprint. According to [Axify](https://axify.io/fr/blogue/velocite-de-developpement), it's a capacity-planning tool: how much work the team can absorb in the next sprint. Nothing more.

The trap is well known and yet everywhere: using velocity as a performance KPI. A 2023 [McKinsey study](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity) shows that organizations measuring dev productivity solely by the volume of code shipped underperform on time-to-market by 20 to 30% compared with those that adopt systemic metrics. When a manager asks "why did velocity drop this sprint?", they turn a capacity indicator into a pressure tool.

### Do story points measure productivity?

No. Story points combine effort, risk, uncertainty, and complexity. They are **subjective by design**: a team that grows more skilled may estimate the same tasks at fewer points without its productivity having dropped at all. According to [Bocasay](https://www.bocasay.com/fr/definition-velocite-quoi-ca-sert/), velocity sometimes decreases over time precisely because the team estimates better.

When velocity becomes a target, developers inflate their estimates. It's Goodhart's law applied to sprint planning: "when a metric becomes a management target, it ceases to be a good measure."

**Scrum velocity was never designed to compare two teams against each other.** Comparing team A's 50 points to team B's 35 is comparing kilometers to miles without converting.

### Why is throughput more reliable?

Throughput counts the number of items shipped to production per unit of time. Not estimated points, not lines of code: the features actually deployed and validated. The metric is objective (an item is either shipped or it isn't) and captures the whole chain, from commit to deployment.

When your throughput is flat while your velocity climbs, the bottleneck is downstream: code review, QA, deployment, business sign-off. That's exactly what the DORA metrics formalize.

## The 4 DORA metrics: the standard that replaces the gut feeling

The DORA program (DevOps Research and Assessment), run by Google Cloud since 2018, has analyzed more than 39,000 professional responses over nine years. The [Accelerate State of DevOps report](https://dora.dev) identifies four key metrics that predict the performance of an engineering team.

### What exactly are the DORA metrics?

Two axes, four indicators.

**Speed axis:**

- **Deployment Frequency**: how often the team deploys to production per period. Elite teams deploy several times a day.
- **Lead Time for Changes**: the time between the first commit and going live in production. Under an hour for the best teams.

**Stability axis:**

- **Change Failure Rate**: the percentage of deployments that cause an incident or a rollback. Under 5% for elite teams.
- **Time to Restore Service**: how long it takes to restore service after an incident. Under an hour.

| DORA metric | Elite team | Average team | Slow team | Trend |
| --- | --- | --- | --- | --- |
| Deployment frequency | Several times/day | Once/week | Once/month | ↑ CI/CD widespread |
| Lead time |  "AI generates code faster. But code is only a third of delivery. The other two thirds (review, test, deployment) absorb the surplus and slow everything down."
>
> Vincent Roye, June 2026

### Why does AI slow delivery when it's poorly framed?

The problem isn't AI itself, it's the downstream overload. When a developer generates three times more code per day, the review queue triples. QA gets bigger PRs. Lead time blows up even as "velocity" appears to soar.

In the DORA/Uplatz report, the analysis is unambiguous: in 2024, AI-assisted code generation accounts for 41% of total output. Yet effective delivery speed fell by 19%. The reason fits in one sentence: the bottlenecks migrated from development to validation.

My experience backs this up. An [AI-augmented developer](https://extradev.fr/en/blog/developpeur-augmente-senior-ia) gains real velocity only if three conditions are met: specs broken into short blocks with precise acceptance criteria, systematic review of the generated code by a senior who knows the architecture, and a CI/CD pipeline that absorbs the flow without a backlog.

Without that framing, AI accelerates the accumulation of technical debt. According to the Uplatz analysis, **nearly half of AI-generated code lands in repositories without being functionally verified**.

## How to improve velocity without cheating

Improving real velocity (measured in DORA, not story points) runs through three levers.

### Should you invest in the pipeline before investing in AI?

Yes. Every manual step between commit and production is a tax on lead time. Infrastructure as Code, automated tests, continuous deployment: these fundamentals cut lead time by a factor of 5 to 10 before AI even enters the conversation.

The second lever is change size. Smaller PRs get reviewed faster, tested faster, break less often. When I [staff a senior dev on a staff-augmentation basis](https://extradev.fr/en/blog/recruter-dev-senior-cdi-regie-180-euros-jour-calcul-12-mois), the rule is always the same: no PR over 300 lines. Beyond that, review time grows exponentially and the failure rate climbs.

The third lever is framing the AI. The real advantage isn't using AI, it's building an industrialized software-production system around it: project context files (CLAUDE.md, ARCHITECTURE.md, CONVENTIONS.md), specs broken into testable tasks, mandatory review before merge. With that framing, an AI-augmented senior with at least 8 years of experience delivers a higher real throughput than two unframed juniors.

### How do you avoid Goodhart's law on dev metrics?

By building a measurement architecture based on the tension between competing metrics. Deployment frequency is checked against the failure rate. Throughput is checked against developer NPS. Code volume is checked against the rework rate (code changed within 14 days of merge).

Google Cloud's [State of DevOps report](https://dora.dev) recommends **measuring systems, not individuals**. When the metrics flag a slowdown, the question isn't "who's working too slowly?" but "which process is creating friction?"

## Frequently asked questions

### How do you measure a dev team's velocity?

Combine the four DORA metrics (deployment frequency, lead time, failure rate, restore time) with throughput (items shipped to production per week). Story points are for sprint planning, not for measuring productivity. A dashboard wired into your CI/CD is enough.

### Does AI really boost developer productivity?

75% of developers report gains (DORA 2024), but the METR study on 246 real issues shows a 19% drop with Cursor Pro and Claude Sonnet. AI speeds up code generation but overloads review, test, and deployment. The real gain only materializes with an automated pipeline and strict spec framing.

### What's the difference between velocity and throughput?

Scrum velocity measures the story points finished per sprint (a subjective estimate, specific to each team). Throughput measures the items actually shipped to production. Throughput is objective, comparable, and captures the whole delivery chain. If velocity climbs but throughput is flat, the bottleneck is downstream: review, QA, business sign-off.

### Are the DORA metrics suited to small teams?

Yes. Deployment frequency and lead time read straight out of GitHub Actions or GitLab CI. The failure rate is derived from tagged hotfixes. Restore time is measured through alerts. No expensive platform is needed for a team of 2 to 5 developers.

### How do you improve a team's velocity without adding pressure?

Three levers: shrink PR size (under 300 lines), automate every manual step of the pipeline, and frame AI usage with broken-down specs. The DORA report shows that elite teams optimize speed and stability in parallel by reducing process friction, not by adding load.

## Sources

- [Measuring Engineering Velocity: DORA & SPACE Frameworks Explained · Uplatz](https://www.youtube.com/watch?v=sSTjkY82hlQ)
- [Agile Metrics Explained: Stop Tracking Velocity! · CodeLucky](https://www.youtube.com/watch?v=3nw7vHSYdtg)
- [Velocity in Agile Explained · Arham Faraaz](https://www.youtube.com/watch?v=BC3gtcagiVc)
- [MYTH: Sprint VELOCITY is Productivity · Agile Coach](https://www.youtube.com/watch?v=Pbu22ZZuAGM)
- [Qu'est-ce que la vélocité de développement et comment la mesurer ? · axify.io](https://axify.io/fr/blogue/velocite-de-developpement)
- [Comment mesurer la vélocité d'une équipe de développement ? · sitenco.com](https://sitenco.com/comment-mesurer-velocite-equipe-developpement/)
- [A quoi sert la vélocité d'une équipe de développement ? · bocasay.com](https://www.bocasay.com/fr/definition-velocite-quoi-ca-sert/)
- [Mesurer la vélocité du sprint de votre équipe · asana.com](https://asana.com/fr/resources/sprint-velocity)
- [DORA / State of DevOps Reports · dora.dev](https://dora.dev)