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

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 are one-on-one and group discussions for deeper exploration of topics.

Diary studies are the collection of data about actions, thoughts, and experiences during work.

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

The plus 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 is counting artifacts: the number of commits, the number of users.

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

Frequency is the rate of events, such as the number of deploys per month or PRs per week.

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

The limitation is that sufficient observability into the toolchain is needed: integrations, data collection, 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.

Measuring software 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.

A key requirement is alignment with company goals and leadership support; without that, measurement turns into reporting with no outcome.

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.

The conclusion was written with contributions from Nathen Harvey, DORA lead at 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 show the practices that help create truly high-performing teams. This year we introduced the first version of the DORA AI capability model, an important step in the evolution of 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 study highlights an important conclusion: we are still in the early stage of AI-assisted development, a period when technologies are changing quickly and practices are only now taking 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. We found with high confidence that when a team is user-centered, AI's positive impact 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 use of AI.

If the user is not at the center of your product strategy, AI will not help and in some cases may even hurt 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 - use DORA's findings to form hypotheses and test them in 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 - use the questions from this year's study as a starting point and adapt 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 right now is not falling behind, but widespread chaotic action with no meaningful result.

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 study is an example of the strength 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.