Measurement frameworks
DORA vs SPACE vs DX Core 4: measuring developer productivity
Engineering leaders are asked whether AI tools are making teams more productive. Four published frameworks come up in that conversation. They measure different things, and they work best together. This guide explains each one accurately and shows how a lead can combine them.
The frameworks at a glance
| Framework | Who publishes it | What it measures | Best used for |
|---|---|---|---|
| DORA metrics | DORA, a research program at Google Cloud | Software delivery performance: throughput and instability | Whether a service ships change quickly and safely |
| SPACE | Researchers from Microsoft Research, GitHub and the University of Victoria (ACM Queue, 2021) | Five dimensions of developer productivity | Choosing a balanced set of measures |
| DevEx | Noda, Storey, Forsgren and Greiler (ACM Queue, 2023) | Developer experience: feedback loops, cognitive load, flow | Finding friction engineers feel |
| DX Core 4 | DX, a developer-productivity company (2024) | Speed, effectiveness, quality and impact | A ready-made combined scorecard |
DORA: software delivery performance
DORA's software delivery metrics are defined on dora.dev. The set grew from four to five in DORA's 2024 research, and DORA now groups them into two factors:
| Metric | Factor | DORA's definition, in short |
|---|---|---|
| Change lead time | Throughput | Time for a change to go from committed to version control to deployed in production |
| Deployment frequency | Throughput | Number of deployments over a period, or time between deployments |
| Failed deployment recovery time | Throughput | Time to recover from a deployment that fails and requires immediate intervention |
| Change fail rate | Instability | Ratio of deployments that require immediate intervention |
| Deployment rework rate | Instability | Ratio of deployments that are unplanned and happen because of an incident in production |
Older articles use "mean time to restore" or "time to restore service" for what is now failed deployment recovery time, and list only the first four metrics. DORA's guidance says the metrics are meant to be applied at the application or service level, and that the aim is to improve a team's performance over time, not to compete with other teams.
In the AI era: DORA's metrics are hard to inflate by generating more code. If AI tools raise deployment frequency while change fail rate or rework rate climbs, the team is going faster, not better.
SPACE: productivity has more than one dimension
"The SPACE of Developer Productivity," by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler, argues that productivity cannot be captured by a single metric. Its five dimensions:
- Satisfaction and well-being: how fulfilled and healthy developers are, and how they feel about their work and tools.
- Performance: the outcomes of the work, such as quality and customer impact.
- Activity: counts of actions, such as commits, pull requests and reviews.
- Communication and collaboration: how people and teams work together.
- Efficiency and flow: whether work progresses with little interruption or delay.
The paper recommends using several metrics across at least three dimensions, and including perceptual measures such as surveys. SPACE is a way to choose metrics, not a fixed list. Activity alone is the dimension AI tools inflate most easily.
DevEx: what engineers experience
"DevEx: What Actually Drives Productivity," by Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, focuses on three dimensions of developer experience: feedback loops (how quickly developers get answers from builds, tests, reviews and people), cognitive load (how much mental effort the work and its systems demand) and flow state (how often developers can work with focus). It combines what people report with what systems record.
In the AI era: AI tools can shorten some feedback loops and lengthen others, such as review. Asking engineers directly is often the fastest way to see which.
DX Core 4: a combined scorecard
DX Core 4 was published by DX, a company that sells developer-productivity tooling, and is presented as unifying DORA, SPACE and DevEx. It uses four dimensions, each with a key metric:
| Dimension | Key metric as published |
|---|---|
| Speed | Diffs (pull requests) per engineer, at team or organization level |
| Effectiveness | Developer Experience Index, a survey-based measure |
| Quality | Change failure rate |
| Impact | Percentage of time spent on new capabilities |
DX states that diffs per engineer should not be used to evaluate individuals. Since pull request counts are easy to raise with AI tools, read the speed dimension together with quality.
Why self-reported speed is not enough
In a randomized trial published in July 2025, the research group METR had experienced open-source developers work on real tasks in their own repositories, with and without AI tools. Tasks took 19% longer when AI was allowed, yet developers estimated afterward that AI had sped them up by about 20%. In February 2026 METR said it believes that slowdown likely no longer applies to current tools, and that it is changing its study design. The lasting lesson for a lead is the gap between perceived and measured speed: ask engineers how the tools feel, and also measure what ships.
A combined approach for an engineering lead
- Start with delivery: DORA's five metrics for each service your team owns.
- Add experience: a short regular survey on feedback loops, cognitive load and flow.
- Add one impact measure: share of time on new capabilities versus maintenance and unplanned work.
- Add AI-specific watch items: review time, rework and reverts, escaped defects. More in measuring engineering work.
- Take a baseline before changing tools, and compare over months, not weeks.
Measure systems, not people. All four frameworks warn, in different words, against turning these measures into individual targets. Used that way they get gamed, and AI tools make gaming easier.
Common questions
Are DORA metrics still four?
DORA now lists five, adding deployment rework rate, and calls the recovery metric failed deployment recovery time.
Which framework should a small team use?
Start with DORA's metrics if you deploy software regularly, plus a short survey. Add more only when you have a question those cannot answer.
Can these frameworks measure AI tool return on investment?
They can show whether delivery, quality and experience changed after adoption. Attributing the change to the tool needs a baseline and a comparison over time. Guidance on running that evaluation is in measuring engineering work.
Should AI acceptance rate be a team goal?
No. It records how often suggestions were accepted, not whether the result was right.
Last reviewed 2026-09-17