DORA vs SPACE vs DevEx: Which Framework, When
THREE FRAMEWORKS, ONE PICK
DORA, SPACE, and DevEx answer different questions - delivery outcomes, productivity dimensions, daily friction. A decision guide for choosing between them.
The band we grade against.
Illustrative example
TL;DR: These three frameworks are different altitudes over the same territory. DORA measures delivery outcomes: four keys, system telemetry, "is our shipping fast and stable?" SPACE is measurement theory: five dimensions, "what would honestly representing productivity even require?" DevEx zooms into the developer's day (feedback loops, cognitive load, flow state): "where does the work itself hurt?" Pick by the question you're actually asking. Most teams need DORA's keys from real telemetry, SPACE as the guardrails around any metric set, and DevEx when the delivery numbers look fine but the humans don't.
At some point every engineering org googles "how to measure developer productivity" and surfaces holding three acronyms and a headache. The frameworks share authors, citations, and a research lineage, which makes them easy to conflate and easy for vendors to blur into one interchangeable dashboard pitch. They answer different questions. Here's which one answers yours.
What DORA measures (and what it doesn't)
DORA is the narrowest and hardest-edged of the three: four metrics - deployment frequency, lead time for changes, change failure rate, failed-deployment recovery time - capturing the speed and stability of software delivery. The decade of research behind it established that the four keys cluster into performance profiles and that speed and stability rise together rather than trading off. The full explainer covers the 2024 bands and their fine print, including the fact that the 2025 report retired the famous elite/high/medium/low tiers in favor of seven team archetypes.
DORA's strength is that it's about outcomes at the system boundary, measurable from pipelines and git history without asking anyone anything. Its equally important limit: it says nothing about why. A rotten lead time doesn't tell you whether the constraint is review queues, deploy trains, or a codebase held together by one exhausted person. And none of the four keys will warn you about the team that hits elite bands while quietly burning out. The keys measure the delivery machine; the humans operating it are out of frame.
Use DORA when the question is "how is delivery actually going?", especially if the current answer is anecdotes.
What the SPACE framework adds
SPACE (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler; ACM Queue, 2021) is not a metric set; it's the theory of why your metric set is probably lying to you. Its core claim: productivity cannot be measured by a single metric or dimension. It names five dimensions: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow. And it issues two operating instructions: measure across at least three of them, and include at least one perceptual measure, because telemetry can tell you a review took 26 hours but only a human can tell you whether that blocked them or nobody cared.
SPACE's sharpest practical contribution is tension by design: choose metrics that check each other, so no single number can be gamed into looking good while the system degrades. Activity up while satisfaction craters is a burnout in progress that a single-metric dashboard would celebrate. The full SPACE walkthrough covers the five dimensions and the anti-surveillance rules in depth.
Use SPACE when someone above you says "measure productivity." It's the defensible answer to a request that, taken literally, has no honest single-number answer.


What the DevEx framework measures
The DevEx framework (Noda, Storey, Forsgren, Greiler; ACM Queue, 2023) descends from the same research lineage but points the lens somewhere new: the developer's lived experience of the work, as the thing that drives productivity rather than a nice-to-have beside it. It identifies three dimensions:
- Feedback loops: how fast and how good the responses are, from tools (builds, tests, deploys) and from people (reviews, answers, decisions).
- Cognitive load: how much mental effort the codebase, tooling, and processes demand before any actual problem-solving begins.
- Flow state: whether the work allows deep, uninterrupted focus, or arrives pre-shredded by meetings, pages, and waiting.
The paper's argument is that improving these drives business performance through efficiency, quality, and retention: the experience isn't downstream of productivity, it's upstream. Notice how concrete the dimensions are compared to SPACE's. "Feedback loops" is measurable today from the same timestamps that power your flow-efficiency decomposition, and "flow state" degrades in exactly the ways interruption research predicts. DevEx leans on paired measurement - perceptions and workflows - so it's survey-forward by design.
Use DevEx when delivery metrics look acceptable but attrition, complaints, or the exit interviews say otherwise. It finds the friction DORA can't see.
DORA vs SPACE vs DevEx: side by side
| DORA | SPACE | DevEx | |
|---|---|---|---|
| What it is | Delivery outcome metrics (4 keys) | Measurement theory (5 dimensions) | Experience framework (3 dimensions) |
| Core question | Is delivery fast and stable? | What would honestly measuring productivity require? | Where does the daily work hurt, and why? |
| Unit of analysis | The delivery system | The metric set itself | The developer's day |
| Primary data | System telemetry (pipelines, git) | Mixed; mandates ≥1 perceptual measure | Perceptions paired with workflow data |
| Great at | Hard outcomes, trend lines, benchmarks | Preventing single-metric theater | Explaining why, early-warning on humans |
| Blind spot | Causes; team health | It's guardrails, not a scoreboard | Needs survey trust + telemetry to act on |
| Misused when… | Keys become individual KPIs | Cited in the deck, ignored in the dashboard | Reduced to an annual satisfaction survey |


Which framework should you use, when
Skip the diplomatic "all three are great." Decide:
- You can't currently say how often you deploy or how long a change takes to ship. DORA, from telemetry, this quarter. Nothing else matters until the delivery scoreboard exists; everything upstream of missing basics is decoration.
- You have delivery metrics and someone wants to expand them. Apply SPACE as the design review: are you covering three dimensions? Is anything perceptual? Do the metrics check each other, or can they all be gamed in the same direction? Fix the metric set before adding to it.
- Delivery looks fine but the team is grinding. DevEx: measure feedback loops and flow interruptions from timestamps, ask about cognitive load directly, and treat the answers as system diagnostics. This is where the team-health signals live.
- Someone proposes any of these for ranking individuals. All three frameworks, and all of their authors, are against you. That unanimity is the least ambiguous finding in this entire research lineage.
The synthesis most teams actually need is small: two-to-four DORA keys pulled from real systems, a SPACE-designed tension pair around them (speed vs quality, activity vs satisfaction), one honest perceptual question per quarter, and DevEx's three dimensions as the vocabulary for what the answers mean.
That's one afternoon of setup. The discipline to keep the numbers describing the system was always the hard part, no matter which acronym is on the dashboard.
Frequently asked
Can you use DORA and SPACE together?
Yes: they were designed by overlapping researchers and slot together naturally. DORA's four keys measure delivery outcomes; SPACE is the design theory for the broader metric set around them. In SPACE terms, the DORA keys are mostly Performance and Efficiency measures; SPACE tells you what to add so they aren't gamed.
Is DevEx replacing DORA?
No. The DevEx framework (Noda, Storey, Forsgren, Greiler, 2023) measures the developer's daily experience (feedback loops, cognitive load, flow state) as a driver of productivity, not as a delivery scoreboard. DORA tells you how delivery is going; DevEx helps explain why, from inside the work.
Which engineering metrics framework should a small team start with?
Start with the two DORA keys you can pull from systems today (deployment frequency and lead time) plus one perceptual question to the team each quarter. That's a SPACE-compliant minimum (multiple dimensions, one perceptual measure) without a survey program you'll abandon by November.
What do all three frameworks agree on?
Three things: no single metric can represent productivity, system data must be paired with human perception, and metrics describe systems. The moment any of these numbers is used to rank individuals, the data degrades into theater, and the frameworks' authors would be first to object.