DORA Metrics Alternatives: Frameworks, Tools and What to Measure

The best alternatives to DORA metrics are SPACE, DevEx and Google's Goals, Signals and Metrics (GSM). None of them replaces DORA. They add what DORA leaves out: how developers experience their work, where time goes between commits, and whether the metrics you track actually serve a goal.

DORA (DevOps Research and Assessment) now defines five software delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. They describe how fast and how safely changes reach production, measured for one application or service at a time. They say nothing about code review flow, focus time, meeting load, collaboration or AI tool adoption, which is where most engineering leaders' questions now sit.

This guide compares the three frameworks with DORA, then covers what to look for in a DORA metrics tool, and how Worklytics measures the parts of engineering work that DORA does not.

Why You Might Want Other Options

DORA's own guidance explains where its metrics stop. They are meant to measure one application or service at a time, so comparing them across teams or rolling them up for a whole organization can mislead. DORA also warns against setting the metrics as goals, since targets like "every application must deploy daily" invite gaming, and against relying on one metric to describe a complex system. (DORA, software delivery performance metrics)

The metrics have also changed more than most dashboards reflect. In 2023 DORA renamed mean time to recover as failed deployment recovery time, so that it only counts recovery from failures caused by a change. In 2024 it added a fifth metric, deployment rework rate, the share of deployments that are unplanned work to fix bugs. If your tooling still reports four keys with MTTR, it is measuring the 2015 definition. (DORA, a history of DORA's software delivery metrics)

The strongest reason to look further is that DORA measures the delivery pipeline, not the people building the software. The 2024 DORA report found that AI adoption raised individual productivity, flow and job satisfaction while reducing software delivery throughput and stability. (DORA, Accelerate State of DevOps Report 2024) A team watching only its DORA metrics would see the dip and miss the gain. The frameworks below are built to see both.

Top Metrics Frameworks for DevOps Teams

Three frameworks are used most often alongside DORA: SPACE, DevEx and GSM. Each comes from a published source, and each answers a different question. SPACE asks what developer productivity is made of. DevEx asks what gets in developers' way. GSM asks which metrics are worth tracking at all.

1. SPACE

The SPACE framework comes from a 2021 ACM Queue paper by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler. Its argument is that developer productivity is about more than activity levels or the efficiency of engineering systems, and cannot be captured by a single metric. (Forsgren et al., The SPACE of Developer Productivity, ACM Queue, 2021) It names five dimensions, and recommends tracking metrics from several of them at once, including at least one that captures how developers feel:

• Satisfaction and well-being - Developer satisfaction and well-being looks at how happy developers are in their roles. Team morale and satisfaction can play a huge role in productivity and performance, so it’s important to regularly look at these metrics through surveys and other means to understand how your developers are feeling about the job.
• Performance - Back to the more technical side of things, performance metrics look at the performance of the team to finish tasks and projects. Performance metrics can often include some of our DORA metrics, like change failure rate. Essentially, performance is looking at output and the quality of that output.
• Activity - Activity metrics measure efficiency and the pace of the work being done. Activity helps you understand the frequency of tasks, how long they take to complete, and how much review work is happening. By measuring activity, you can find inefficiencies and bottlenecks in your team’s processes and address them as needed.
• Communication and collaboration - Communication and collaboration are essential for any DevOps team. Measuring communication and collaboration metrics can help you understand if your team can easily and effectively work with each other. You can look at metrics like frequency of communications, access to leadership, meeting participation and more to better understand collaboration and communication among your team.
• Efficiency and flow - This measures a DevOps team’s ability to smoothly progress throughout the software development cycle with minimal disruptions. It looks at how your team uses their time and how they maximize their output with the time used.

DORA vs SPACE

Both DORA and SPACE aim to improve software development, but DORA has the narrower scope. DORA covers five delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. They judge the delivery process. SPACE looks past delivery at satisfaction, collaboration, focus and flow, so DORA's metrics fit inside SPACE's Performance and Activity dimensions. The key differences:

• Scope - DORA is specific to software delivery performance. SPACE covers a broad spectrum of software delivery, operational performance, developer satisfaction and more to give you a more complete picture.
• Focus - DORA is focused on four specific metrics. SPACE can include many metrics, including the ones used in the DORA framework.

In summary, while both frameworks aim to enhance software development productivity, SPACE offers a more comprehensive and adaptable approach that complements the focused metrics provided by DORA.

2. DevEx

DevEx is the developer experience framework published in ACM Queue in 2023 by Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler. It focuses on the lived experience of developers and the friction they meet in everyday work, and it distills that experience to three core dimensions. (Noda et al., DevEx: What Actually Drives Productivity, ACM Queue, 2023)

The paper recommends measuring each dimension in two ways: how developers perceive it, through surveys, and how it shows up in workflows, through system data such as review turnaround or build time. The three dimensions are:

• Feedback loops - Feedback loops are the speed and quality of responses to actions performed. In other words, if a developer completes a task that requires feedback, like approval from code reviewers, the response should be expedient. A fast feedback loop has minimal friction and allows a developer to get through their tasks with minimal disruptions or delays.
• Cognitive load - Cognitive load looks at the level of mental processing required for a developer to complete a task. Using complex tools, learning new processes and dealing with poor documentation can all add to cognitive load. To decrease cognitive load and make things easier, developers need good processes in place and the right resources to do their jobs.‍
• Flow state - Flow state looks at when a developer is fully immersed and enjoying their work, or “in the zone.” Flow state disruptions can be frustrating, so workplaces and workflows should be structured to provide the optimal environment for developers to frequently be in a flow state.

DORA vs DevEx

DORA and DevEx both aim at continuous improvement, but they measure different ends of the work. DORA measures outcomes at the end of the pipeline. DevEx measures the conditions developers work in, upstream of those outcomes: how long they wait for reviews and builds, how much complexity they carry, and how often they get uninterrupted time. A team with strong DORA numbers can still have a poor developer experience, and DevEx data usually explains a DORA decline before the DORA metrics do.

3. GSM (Goals, Signals & Metrics)

GSM stands for Goals, Signals and Metrics. It is the method Google's engineering productivity research team uses to decide what to measure, described in the Software Engineering at Google book. A goal is the outcome you want, written without reference to any metric. A signal is how you would know you had reached it, whether or not it can be measured directly. A metric is the measurable proxy for a signal. Working in that order prevents what the book calls the streetlight effect: tracking the metrics that are easy to get rather than the ones that matter. (Software Engineering at Google, chapter 7, Measuring Engineering Productivity)

An example of GSM in action is identifying the problem that many developers are experiencing burnout. The goal then is to reduce burnout for developers. Signals that indicate progress are that your developers aren’t reporting feeling burnt out and that they have more focus time to do their tasks. Metrics that could help inform your strategy include work-life balance, frequency of meetings, amount of overtime worked, etc. 

With GSM, you can find the source of burnout, ensure that your developers are getting the resources and time they need to avoid burnout and ultimately reduce those burnout rates significantly.

DORA vs GSM

DORA and GSM are not competing frameworks. DORA is a fixed set of delivery metrics. GSM is a way to choose metrics for any goal, and it can lead you to DORA metrics when the goal is delivery speed or stability, or to focus time and review turnaround when the goal is a better developer experience. Used together, GSM decides the question and DORA, SPACE or DevEx supply the measures.

How to Choose a DORA Metrics Tool

Many people who search for DORA alternatives are really choosing a tool. Most products that report DORA metrics fall into three groups, and the right one depends on what you need to see beyond the pipeline.

• Version control and CI/CD platforms. The systems that run your deployments can report deployment frequency, change lead time and failure rates directly, because the events happen inside them. They are the most accurate source for the five DORA metrics and usually the cheapest. They stop at the pipeline.
• Engineering intelligence tools. These connect to repositories and issue trackers and add cycle time, review flow and planning metrics on top of DORA. They are built for engineering managers and often report down to the individual, so check how they handle privacy before rolling them out.
• People and work analytics platforms. These bring code review data together with calendars, chat, documents and AI tool usage, and report at team level across the whole organization, not only engineering. They are the right fit when the questions are about focus time, meeting load, collaboration and AI adoption, and when HR or people analytics teams will use the data too.

Whichever group you choose, ask these questions before you buy:

1. Which DORA definition does it use? Look for failed deployment recovery time and deployment rework rate, not only MTTR and change fail rate. A tool on the four-key model is three years behind DORA's own research.
2. Does it report per service or per team? DORA metrics are meant for one application at a time. Team-level reporting is right for everything else: review turnaround, focus time, meeting hours and AI adoption.
3. What else does it cover? If you plan to use SPACE or DevEx, you will need review turnaround, focus time, meeting load and a survey channel, not just deployment events.
4. How does it protect individuals? Ask whether identifiers are pseudonymized, whether results are shown only for groups above a minimum size, and whether message or code content is read at all.
5. Can it break results down by your org structure? Department, manager and role breakdowns need an HRIS connection. Without one, every tool reports by repository.
6. Does it give you context? Benchmarks against other organizations turn a number into a position, which is what executives ask for.

A Holistic Way to Measure Developer Productivity

Measuring developer productivity is not a one-size-fits-all exercise. The teams that get it right mix frameworks: DORA for the delivery pipeline, SPACE or DevEx for the people building it, and GSM to keep the metric list honest. What they share is a small set of team-level measures, reviewed as trends rather than as scores for individuals.

Getting that view needs data from more than the deployment pipeline: code review, calendars, chat and the AI tools engineers now use every day. That is where a platform like Worklytics fits, as a complement to your DORA numbers rather than a replacement for them.

What Worklytics Measures Alongside DORA

Worklytics does not compute DORA's deployment metrics. Your CI/CD platform is the right source for those. What Worklytics adds is the rest of engineering work, measured at team level from the tools you already use:

• Code review flow from GitHub: pull request cycle time, reviewer response time (from review request to approval), pull requests opened, merged and reviewed, review comments and commits.
• Delivery of planned work from Jira: issues created and completed per team per week.
• Focus and meeting load from calendars and chat: hours in focus blocks of at least two hours, hours fragmented, recurring meetings, after-hours meetings, meetings with 10 or more attendees and manager 1:1s.
• AI coding assistant adoption: active days for GitHub Copilot; lines added and accepted for Cursor; sessions, lines added and removed, and commits and pull requests attributed to Claude Code.

Every metric is reported for groups, not individuals. Personal identifiers are pseudonymized (hashed with SHA-256) before analysis, no message or code content is read, and results are only shown for groups above a minimum size, typically 5 to 8 people. Peer benchmarking against other organizations is available in beta, so a team's review turnaround or focus time can be read against a benchmark rather than in isolation. Worklytics connects to more than 25 tools, including GitHub, Jira, Google Workspace, Microsoft 365, Slack and Zoom.

For the full metric set and how to act on it, see how to measure and improve software engineering productivity. For the AI side, see whether AI coding assistants are really saving time.

Get a Better View of Your Workflow

DORA tells you how the pipeline performs. Worklytics shows how your engineering teams work around it: review flow, focus time, meeting load and AI adoption, by team and over time, with productivity insights that leaders can act on without watching individuals. Ready to see it on your own data? Request a demo.

Frequently Asked Questions

What are the best alternatives to DORA metrics?

The three most used are SPACE, DevEx and GSM. SPACE covers developer productivity across satisfaction, performance, activity, collaboration and flow. DevEx measures feedback loops, cognitive load and flow state. GSM is Google's method for choosing metrics from goals and signals. Most teams keep DORA for delivery and add one of these for the rest of engineering work.

What are the five DORA metrics?

Since 2024 DORA uses five metrics in two groups. Throughput: change lead time, deployment frequency and failed deployment recovery time. Instability: change fail rate and deployment rework rate. Failed deployment recovery time replaced mean time to recover in 2023, and deployment rework rate was added in 2024.

What is the difference between DORA and SPACE metrics?

DORA measures the software delivery pipeline with five metrics for one application or service at a time. SPACE measures developer productivity across five dimensions, including satisfaction, collaboration and flow, and recommends mixing metrics from several dimensions. DORA's metrics fit inside SPACE's performance and activity dimensions, so the two are usually used together.

What should I look for in a DORA metrics tool?

Check which DORA definition it uses (five metrics, not four), whether it reports per service for DORA and per team for everything else, what it covers beyond deployment events, how it protects individuals, whether it can break results down by your org structure, and whether it offers benchmarks. Your CI/CD platform is usually the most accurate source for the DORA metrics themselves.

Does Worklytics measure DORA metrics?

No. Worklytics does not compute deployment metrics, which come from your CI/CD platform. It measures the rest of engineering work at team level: pull request cycle time, reviewer response time, pull requests merged and reviewed, Jira issues completed, hours in focus blocks, meeting load and AI coding assistant adoption, with personal identifiers pseudonymized and results shown only for groups above a minimum size.