Use DORA vs SPACE together
Your AI coding rollout is expanding, but reviewers say they're spending longer checking changes. The board wants to know whether delivery improved. For this DORA vs SPACE decision, we'd combine delivery evidence with developer feedback before changing the rollout.
DORA's guidance, updated January 5, 2026, focuses on delivering software safely, quickly and efficiently. The February 2021 SPACE publication argues that developer productivity needs more than one metric or dimension. These historical SPACE principles help frame the investigation; they aren't evidence about current AI tools.
We think choosing a single framework gets the desire for consistency right, but leaves this question too narrow. Combine the lenses, not their measurements into one score.
Sources: DORA | DORA’s software delivery performance metrics, The SPACE of Developer Productivity: There's more to it than you think - Microsoft Research
Compare scope before choosing measures
The DORA vs SPACE framework comparison below separates documented scope from our suggested implementation. DORA's January 2026 guidance suggests measuring code review duration when investigating constraints. The 2021 SPACE paper describes five dimensions and recommends surveys for satisfaction and well-being.
SPACE survey responses describe developers' perceptions, not measured causal productivity. Neither framework establishes that growing AI adoption causes additional review work.
Use the same five criteria to compare DORA vs SPACE metrics. Data collection and decisions in this table are editorial suggestions, rather than mandatory framework specifications.
| Criterion | DORA | SPACE |
|---|---|---|
| Scope | Safe, quick, efficient delivery | Satisfaction, performance, activity, collaboration, flow |
| Required data | Complete requirements: unknown; suggest delivery records | Complete requirements: unknown; suggest selected records and feedback |
| Employee feedback | Role not documented here | Surveys recommended for satisfaction and well-being |
| Interpretation limits | Review duration doesn't explain its cause | Multiple dimensions needed; feedback captures perceptions |
| Decisions supported | Suggested: locate delivery constraints | Suggested: investigate experience alongside delivery |
Sources: DORA | DORA’s software delivery performance metrics, The SPACE of Developer Productivity: There's more to it than you think.: Queue: Vol 19, No 1, The SPACE of Developer Productivity: There's more to it than you think - Microsoft Research
Separate waiting from active review
Start with one project. Following DORA's January 2026 suggestion to examine review duration, we'd distinguish time waiting for a reviewer from time spent actively reviewing. A longer queue and a harder review call for different investigations.
Our practical choice is to keep operational observations and developer responses side by side. A blended score would hide the disagreement you need to investigate.
The following is a suggested collection plan, not a validated instrument or a complete framework implementation.
- Delivery records: record delivery timing and review waiting time, active effort, rounds and change size.
- Developer feedback: ask consistently about review difficulty, interruptions, satisfaction and collaboration.
- Suggested questions: “What made this review difficult?” and “Where did you wait for another person?”
- Context: note workload mix, staffing, review practices and AI usage patterns as possible explanations.
Sources: DORA | DORA’s software delivery performance metrics
Test explanations before changing the rollout
Imagine a team where review queues lengthen while reviewers report unchanged difficulty. As an editorial hypothesis, reviewer availability deserves investigation before you assume AI-generated changes are harder to check. If active effort rises instead, inspect comparable changes and ask what required extra checking.
In our view, DORA and SPACE metrics are most useful when they help you choose a specific intervention. We'd skip a blanket rollout change until you've identified the constraint you intend to address.
Use this suggested sequence to make that decision reviewable.
Choose the constraint you'll address
For additional adoption context, AI Adoption Score's AI Adoption Barriers survey identifies 18 barriers across six areas, names responsible owners in IT, leadership, management or training, and classifies the main gap as skills, conditions or motivation. Use that context to decide whether to investigate access, working conditions or skills.
Software Quality Management reviews one software project's engineering practices in 14 areas. It adds a project-practice perspective to your investigation.
Bring your next review meeting one observed constraint, one competing explanation and one proposed change. Measure the bottleneck before changing the rollout.
Frequently asked questions
Who should own the investigation?
Assign one engineering leader to coordinate it. As editorial guidance, ask a delivery or DevOps colleague to maintain operational definitions and a team representative to coordinate feedback. Agree who can approve the eventual practice change so the investigation ends with an accountable decision rather than another reporting task.
How long should the observation period be?
Choose a period that includes enough comparable work to support a useful discussion. As editorial guidance, avoid setting a universal duration: release rhythms and project workloads differ. Record unusual incidents, absences and deadlines so you can judge whether the next observation period offers a reasonable comparison.
Should individual developers be ranked?
Keep this investigation focused on the team's review process. As editorial guidance, use individual detail only where necessary to understand a handoff or task, and agree access beforehand. A ranking would change the purpose of the exercise from identifying a process constraint to judging people against an incomplete picture.
