The SPACE framework: five dimensions, not five metrics
SPACE is a framework for choosing developer productivity metrics across five dimensions, not a set of five metrics. What each means, and DORA vs SPACE.
The SPACE framework is a way to choose developer productivity metrics, not a set of five metrics. It names five dimensions (Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow) and asks you to measure across at least three of them, with at least one measure of how people perceive their work.
That correction matters because many explainers present SPACE as five numbers to collect. The paper that introduced it argues the opposite: productivity “cannot be reduced to a single dimension (or metric!),” and the point of the framework is to pick a small set of metrics that pull against each other.
Where SPACE comes from
SPACE was published in 2021 in ACM Queue (volume 19, issue 1) as “The SPACE of Developer Productivity: There’s more to it than you think,” by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler. The authors were researchers at GitHub, the University of Victoria and Microsoft. Forsgren is also a co-author of Accelerate and led DORA, so the two frameworks share a lineage; the DORA metrics chapter covers that side.
It was written as the pandemic sent most developers home, which the authors called a rare “natural experiment” in how productivity works. It opens by taking apart five myths:
- Productivity is all about developer activity.
- Productivity is only about individual performance.
- One productivity metric can tell us everything.
- Productivity measures are useful only for managers.
- Productivity is only about engineering systems and developer tools.
Each myth maps to a design choice: activity is one dimension of five, every dimension can be read at individual, team and system level, and “invisible” work such as mentoring and knowledge sharing counts, even though it is “often not measured.”
SPACE is a framework, not five metrics
The authors describe SPACE as a way “to choose metrics carefully in a way that reveals not only what those metrics mean, but also what their limitations are if used alone or in the wrong context.” Its example metrics are a menu, and activity metrics in particular “serve as templates to start with and should be customized.”
The five SPACE dimensions
The paper’s Figure 1 gives example metrics at three levels: one person, a team or group, and end-to-end work through a system. A selection:
| Dimension | Paper’s short definition | Individual | Team or group | System |
|---|---|---|---|---|
| Satisfaction and well-being | How fulfilled, happy and healthy one is | Developer satisfaction; satisfaction with code reviews assigned | Developer satisfaction; retention† | Satisfaction with the engineering system (e.g. CI/CD pipeline) |
| Performance | An outcome of a process | Code review velocity | Code review velocity; story points shipped† | Customer satisfaction; reliability (uptime) |
| Activity | The count of actions or outputs | Code reviews completed; coding time; commits; lines of code† | Story points completed† | Frequency of deployments |
| Communication and collaboration | How people talk and work together | Code review score (quality or thoughtfulness); PR merge times | PR merge times; knowledge sharing or discoverability | Knowledge sharing, discoverability (quality of documentation) |
| Efficiency and flow | Doing work with minimal delays or interruptions | Productivity perception; lack of interruptions | Code review timing; handoffs | Velocity/flow through the system |
† The paper’s own warning: “Use these metrics with (even more) caution”, because they can proxy more things.
Satisfaction and well-being covers how fulfilled developers feel with their work, team, tools and culture, and how healthy and happy they are. Surveys are often the best way to capture it. Suggested measures include employee satisfaction, developer efficacy (having the tools and resources to get work done) and burnout. SPACE also floats satisfaction as a possible leading indicator: a drop in satisfaction and engagement could signal burnout ahead.
In its pandemic example, commits and pull-request merge speed went up in some places while qualitative data showed some people were struggling with their well-being. Activity data alone would have called that a good quarter. System metrics can miss that human side of the work. Survey answers are also only as candid as people feel safe to be, which is why psychological safety matters to any measurement plan.
Performance is the outcome of a system or process, best judged by what it achieved rather than how much it produced. Put simply: did the developer’s code reliably do what it was supposed to do? Example measures fall under quality (reliability, absence of bugs, service health) and impact (customer satisfaction, adoption, feature usage, cost reduction).
Activity is a count of the actions or outputs completed while doing the work: commits, pull requests, code reviews, builds, deployments, incidents handled. It’s the easiest dimension to collect, since a well-designed engineering system captures it. It should “never be used in isolation” to judge individual or team productivity.
Communication and collaboration covers how people and teams communicate and work together. Proxies include discoverability of documentation and expertise, how quickly work is integrated, the quality of reviews, network metrics showing who works with whom, and onboarding time and experience for new members.
Efficiency and flow is the ability to make progress with few interruptions or delays, alone or through a system. Examples include handoffs, interruptions, perceived ability to stay in flow, and time through a system (total, value-added and wait time). This is where SPACE cites DORA: deployment frequency and lead time for changes appear as examples of metrics that monitor flow. Flow metrics in the Kanban sense, covered in the lead time vs cycle time chapter, fit here too.
How to use SPACE well
The paper’s guidance is short and specific:
- At least three dimensions. Several metrics across multiple dimensions, with “at least three” recommended.
- At least one perception measure. “At least one of the metrics include perceptual measures such as survey data,” because “perceptual data may provide more accurate and complete information than what can be observed from instrumenting system behavior alone.”
- Tension is the point. Metrics from different dimensions will pull against each other, and that is “by design.” Speed metrics next to quality and satisfaction make any one of them harder to game quietly.
- A handful, not a dashboard. “Having too many metrics may also lead to confusion and lower motivation.”
- Teams, not individuals. Report “only anonymized, aggregate results at the team or group level.” Individual analysis is for developers who opt in, for their own use.
- Check for bias. The paper flags three: women are more likely to receive negative code review comments, year-long windows penalize people who took parental leave, and cultures differ in how high they score perception questions. So compare a group with its own baseline.
Measuring each dimension: surveys and system data
| Dimension | From systems | From a survey (example questions) |
|---|---|---|
| Satisfaction and well-being | Retention (lagging and noisy, per the paper) | “How satisfied are you with our tools and pipeline?” “How sustainable was your workload this month?” |
| Performance | Escaped defects, uptime, feature usage | ”How confident are you that what we ship works as intended?” |
| Activity | Commits, PRs, reviews, deploys, incidents | Rarely needed; the systems already count it |
| Communication and collaboration | Review turnaround, time to integrate, onboarding time | ”Can you find the documentation or expert you need?” “Are reviews useful?” |
| Efficiency and flow | Handoffs, wait time, lead time, DORA throughput | ”How often were you interrupted in a typical day?” “How often could you get into flow?” |
A practical set for a product team might be: a quarterly satisfaction survey (S), change fail rate (P), PR merge time (C), and a perceived-flow question (E). That’s four metrics across four dimensions, two from systems and two from people. If you’re starting from nothing, that’s the set we’d pick: a handful of metrics across at least three dimensions, with perception data in the mix, which is what SPACE asks for.
TeamRetro’s SPACE Framework Health Check is a team survey, so it captures how the team experiences each dimension, including Activity, which the paper expects to come from system data.
DORA vs SPACE
DORA and SPACE answer different questions, and they work well together.
| DORA | SPACE | |
|---|---|---|
| What it is | A fixed set of five software delivery metrics | A framework for choosing productivity metrics across five dimensions |
| Question it answers | How fast and how safely does this service get changes to production? | Is the way we measure developer productivity balanced? |
| Unit | One application or service | Individual, team or group, and system |
| Measures | Change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate | Whatever you choose: at least three dimensions, at least one perceptual |
| Data | Delivery pipeline and incident records, or survey answers (DORA’s own research uses a survey) | A mix of system data and surveys, by design |
| People’s experience | Not one of the five metrics | Satisfaction and well-being is a dimension |
| Source | DORA research program; five-metric model since the 2024 report | ACM Queue paper, 2021 |
| Common misuse | Turning the metrics into targets; comparing unlike services | Treating it as five metrics; scoring individuals |
How they fit together. DORA’s metrics slot into SPACE. Deployment frequency appears in the paper’s Activity column at system level, and lead time for changes is cited under Efficiency and flow. Change fail rate and recovery time sit naturally under Performance, whose examples include reliability and ongoing service health. A team already reporting DORA has the system half of a SPACE set; adding a satisfaction measure and a collaboration measure makes it balanced.
Asking “how is delivery going on this service”? Start with DORA. Asking “are we measuring developers fairly and completely”? Use SPACE to choose the set. For the perception-led approach that followed, see developer experience metrics; for every framework side by side, the agile metrics hub.
Frequently asked questions
What does SPACE stand for?
Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow. The five dimensions come from the 2021 ACM Queue paper The SPACE of Developer Productivity by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler.
Is SPACE a set of metrics?
No. SPACE is a framework for choosing metrics. The paper offers example metrics for each dimension at individual, team and system level, but it expects you to pick a handful that fit your context, across at least three dimensions, including at least one perception measure such as survey data.
What is the difference between DORA and SPACE?
DORA is a fixed set of five software delivery metrics for one application or service: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. SPACE is a framework for choosing developer productivity metrics across five dimensions, including satisfaction and collaboration, which DORA’s metrics don’t cover. DORA measures can serve as part of a SPACE set; the paper itself cites deployment frequency and lead time as flow measures.
How many SPACE dimensions should you measure?
At least three, per the paper, with at least one perceptual measure such as survey data. The paper also warns against too many metrics: a handful across three or more dimensions is usually enough to show the trade-offs without overwhelming the team.
Can SPACE be used to measure individual developers?
The paper advises reporting only anonymized, aggregate results at team or group level, and notes that reporting individual productivity isn’t legal in some countries. It sees value in individual analysis for developers themselves, on an opt-in basis.
Related reading
- Agile and engineering metrics: the hub, with every framework side by side.
- What are DORA metrics?: the five delivery measures that make up the system half of most SPACE sets.
- Developer experience and productivity metrics: DevEx and DX Core 4, the frameworks that followed SPACE.
- Health checks and maturity models: when perception data beats system data.
- From numbers to actions: taking a SPACE set into a retro and turning it into a change.