DORA 2025, Part 9. How to choose the right metrics and frameworks to measure development and AI impact in IT organizations

Measuring the development process helps drive real change.

But it is a difficult task: first you need to understand what is worth measuring and what can actually be measured.

The key is to use metrics not for the numbers themselves, but to change how the team and the organization as a whole work.

For this, it is better to rely on established frameworks.

A framework breaks a broad concept, such as developer experience, into specific measurable elements like speed, quality, satisfaction, and so on.

When the industry or academia talks about engineering metrics, the frameworks most often mentioned are SPACE, DevEx, and HEART.

Choosing the right framework can be difficult, but it is a key step. Where should you start? Define which decisions you want to make based on data.

Different frameworks serve different purposes.

They are usually focused on three areas:

Each of these groups offers its own perspective on the evolution of the engineering system and how it should be measured.

To determine which framework best fits your organization's goals, it helps to think of frameworks as the why behind measurement.

They help explain why you are measuring and what actions should follow from the data you collect.

Frameworks set the lens through which you view the data and help ensure your efforts align with organizational goals.

To choose a framework, you can ask yourself:

What has changed that makes measurement necessary?

How will you use the insights?

What decisions or improvements will measurement enable?

Next comes the what - the metrics themselves.

These are the core concepts that feed the framework, such as velocity metrics or usage metrics.

There are usually two main approaches to data collection.

The first is self-reported data: collecting information directly from developers about their experience.

Surveys are answers to questions about opinions, satisfaction, and perceptions of different aspects of work.

Interviews and focus groups - individual and group discussions for deeper exploration of topics.

Diary studies - collecting data about actions, thoughts, and experiences during work.

The main advantage of self-reported data is its ability to capture subjective experience and things that cannot be measured automatically: satisfaction, well-being, and perceived effectiveness.

The advantage is that it does not require complex instrumentation or deep observability into toolchains.

But there are also limitations: challenges with standardization, comparison across teams, and scaling.

Subjective data leads to variation in interpretation and vulnerability to bias (for example, recall bias and social desirability bias).

The second approach is logs-based measures: metrics extracted from the systems and tools developers use. Examples:

Quantity means counting artifacts: number of commits, number of users.

Time - how long an activity takes, such as coding or review time.

Frequency is the rate of events: for example, the number of deployments per month or PRs per week.

The main advantage is continuous, standardized data at scale that provides a detailed view of activity.

The limitation is that you need sufficient observability into the toolchain: integrations, data collection, and infrastructure.

It is also important to understand that logs are not absolutely objective.

Instrumentation approaches vary, errors are possible, and interpretation always depends on context and can be biased.

You may ask: does the arrival of AI in development change everything?

Are the existing frameworks still enough, or do we need new ones?

Any technology transformation creates the impression that metrics must be rebuilt from scratch.

In practice, the changes are usually much more specific.

If your goal is to understand how AI affects the developer experience, it is enough to update a small subset of metrics while keeping the overall measurement structure.

You do not need to abandon the entire framework. On the contrary, existing metrics provide a baseline against which shifts can be seen. For example, you can add indicators for AI suggestion adoption, model quality, or trust in the model, while keeping the existing developer experience metrics such as perceived productivity, review time, and so on.

As more advanced AI tools emerge, the roles themselves and the set of tasks in development will change.

Metrics will need to adapt to new user profiles and changed processes, but the goals of measuring developer experience will likely remain the same.

If the goal does not change, there is no need to change the framework either; it is enough to expand the set of metrics.

Even if goals do change, that does not mean measurement has to start over.

Many metrics fit multiple frameworks, so they can be quickly reassigned to new tasks.

Measuring development processes is a complex and ongoing task.

There are many frameworks and approaches, but any of them is only useful when the organization can act on the data it gets.

The key requirement is alignment with company goals and executive support; without that, measurement turns into reporting with no results.

A deliberate choice of framework and metrics helps build a sustainable measurement system.

If you follow the PDCA cycle, the work may look like this: Plan: define goals, choose the right framework, and secure leadership support. Do: establish baseline metrics and try changing part of the process. Check: measure again and assess progress toward the goals. Adjust: adapt the approach based on the new data.

We do not propose a single best framework.

The approach should fit your goals: the right one is the one that helps you make decisions and motivates the organization to act.

Although frameworks differ in structure and emphasis, many of their metrics overlap.

This means that metrics introduced today can be reused and adapted as goals or context change.

Conclusion written with the participation of Nathen Harvey - Head of DORA, Google Cloud.

For more than a decade, DORA has remained a reliable guide for the engineering community, helping teams become stronger and more effective.

The industry is changing quickly: AI, platform engineering, and new ways of organizing development are entering the workflow.

But our mission remains the same: to study and highlight practices that help create truly high-performing teams. This year, we introduced the first version of the DORA AI capabilities model, an important step in advancing our research.

As companies navigate the complex process of adopting AI, this model provides a grounded, data-driven structure.

It shows seven key capabilities that amplify AI's positive impact on important organizational outcomes.

A clear and open company stance on AI use

Internal data available for AI

We see it as a starting point for further dialogue with the DORA community and with companies that are introducing AI into development processes.

We would be glad to learn how you apply these findings in practice, and we will continue refining and developing the model in future research.

This year's research reveals an important conclusion: we are still at an early stage of AI-assisted software development, when technologies are changing rapidly and practices are only beginning to take shape.

Early attempts to standardize here are premature.

Simply introducing AI tools does not lead to transformation.

Moreover, AI's impact on team performance depends directly on one critical factor: user focus. With high confidence, we found that when a team is user-oriented, the positive impact of AI on its work increases.

When that focus is missing, introducing AI can worsen team performance.

This conclusion highlights a key condition for success: a deep understanding of end users is not a bonus, but a required foundation for effective AI use.

If the user is not at the center of your product strategy, AI will not help - and in some cases may even harm team performance.

This year's report findings are complex and may seem contradictory in places.

This is a normal reflection of a rapidly changing environment.

We suggest treating the findings not as strict instructions, but as hypotheses for experiments within your team.

Here is how you can apply these ideas in practice:

Run experiments in your organization by using DORA findings to form hypotheses and test them with your teams.

This will help you better understand your operational context and identify the areas where improvements will have the greatest impact.

Run internal surveys by using questions from this year's study as a starting point and adapting them to your needs.

Add more nuanced questions that are relevant to your teams and current projects.

Look at the platform as a whole: improving one feature does not fix a weak platform.

Treat internal platforms as products: improve the full developer experience chain, from feedback to automation.

Share what you learn - when you run experiments and gather insights, spread that knowledge across the organization through reports, internal communities of practice, or informal conversations.

The goal is to build a culture of continuous learning.

The main risk in the current situation is not falling behind, but widespread, chaotic action without meaningful results.

Choose approaches and frameworks that fit your organization and drive meaningful change.

Thank you for engaging with our research.

We invite you to continue the journey with us.

Share your experience, learn from peers, and find inspiration by joining the DORA community: https://dora.community.

The DORA research is an example of the power of a global community united by a common goal.

We are grateful to the thousands of researchers, experts, practitioners, leaders, and change agents who generously share their knowledge and experience.

This report is a direct result of collective work.

We hope the research results will help you and your teams create real change and build a culture of continuous improvement within your organizations.