What is the difference between BVSSH, DORA, SPACE and DevEx metrics?

When whispers of ‘keyboard tracking’ started circulating this triggered a huddle with my client about how to explain to well-intentioned yet traditionally minded SVPs the dangers of confusing activity with efficiency.

We talked through a number of efficiency measurement systems that have become widely accepted over the past decade. Some were already in place in the organisation (DORA) and others were a work in progress.

Thankfully for this organisation, the exercise resulted in a shift from keyboard tracking activity towards renewed SVP interest and understanding of far more powerful and mature approaches.

I thought it would be worthwhile to share a brief summary of these efficiency measurement systems, in case similar questions should arise in your context. A number of respected thought leaders occupy this space. This article will compare approaches advocated by Nicole Forsgren^2,3,4, Jonathan Smart ⁵, Abi Noda ² and Margaret Ann-Storey ^2,4.  These can be seen as complementary, whilst they offer a different focus.

This article does not aim to provide a definitive descriptions - for that I'd urge you to please go back and read the source, the details of which are all provided in the references section. I'd welcome any questions and thoughts you may have on this topic, as we are all continually learning.

BVSSH, SPACE, DevEx and DORA are all measurement systems designed to support performance improvement. The last three focus on software development - the first is a more generalised approach for improving business outcomes. 

Here's a breakdown of their differences and how they relate:

SUMMARY

FURTHER EXPLANATION

1. BVSSH (Better Value Sooner Safer Happier)

• Focus: An outcome-oriented philosophy for improving organisational results whilst creating a more humane world of work.

  
  

• Scope: Broadest of the approaches, revealing how an organization's ways of working is continually improving overarching business outcomes - both in terms of What the organisation is seeking to achieve and How it is doing that. BVSSH is not just IT or software delivery. BVSSH applies to any function where work is done. As part of this balance it includes the measuring of Value delivered (“delivering the right thing”) as well as Risk and Control (“delivering the thing right”).

  
  

• Key Outcomes (B.V.S.S.H.):

  • Better: Quality, fewer defects, improved process resilience, proactive work.

  • Value: Delivering what is truly valuable to the customer/organization, measured by business outcomes (e.g. Usage telemetry, AARRR metrics, pains/gain trends, product & business value, OKRs).

  • Sooner: Speed, flow, time to market, time to learning, reduced lead time.

  • Safer: Governance, risk, compliance, security, data privacy, resilience (achieving speed with control).

  • Happier: Well-being and engagement of colleagues, customers, citizens, and impact on the climate.

    
    

• Purpose: To provide a feedback loop on the continuous improvement of what and how work happens. The goal is to balance these five outcomes rather than optimizing one at the expense of others. Design Thinking, Agile, Lean, DevOps and other working practices are simply means to an end, not goals in themselves. BVSSH emphasises the impact achieved by improving all such ways of working. Used to incentivise an ongoing focus on continuous improvement and removal of impediments.

  
  

2. SPACE Framework

• What it is: A holistic, multi-dimensional framework for understanding and measuring developer productivity and well-being. It goes beyond simple output metrics.

  
  

• Primary Focus: Comprehensive understanding of developer experience and team performance.

• Scope: Broader than DORA, applicable to software engineering teams, considering both technical output and human factors.

  
  

• Key Dimensions (S.P.A.C.E.):

  • Satisfaction and Well-being (e.g., job satisfaction, burnout, psychological safety)

  • Performance (e.g., quality, effectiveness, user satisfaction)

  • Activity (e.g., code commits, PR volume)

  • Communication and Collaboration (e.g., team dependencies, knowledge sharing)

  • Efficiency and Flow (e.g., lead time, interruptions, context switching)

    
    

• Purpose: To provide a balanced view of productivity, combining quantitative data (from systems) with qualitative data (from surveys/perceptions). It aims to foster a healthier and more effective development environment. For example, which data would you value more: perception from 100’s of Developers about whether end to end lead time is actually improving (survey), or calculated data from CI/CD tools. SPACE recognises both as valid sources of Lead Time data.

  
  

3. DevEx Metrics2 (Developer Experience Metrics)

• What it is: Often considered an application or subset within the SPACE framework's dimensions (especially S, C, E). DevEx drills down into the factors influencing a developer's day-to-day work experience.

  
  

• Primary Focus: Identify friction and flow in a software developer's daily workflow.

• Scope: The individual developer's journey and interaction with their development environment.

  
  

• Key Dimensions:

  • Feedback Loops: How quickly developers get information (e.g., build times, test results, code review speed).

  • Cognitive Load: The mental effort required to understand and use tools, systems, and codebases.

  • Flow State: The ability to achieve and maintain deep, uninterrupted work.

    
    

• Purpose: To identify specific pain points and opportunities to improve the development environment, tools, and processes from the developer's perspective, thereby boosting productivity, satisfaction, and retention.

  
  

4. DORA Metrics (DevOps Research and Assessment)

• What it is: A set of four key quantitative metrics derived from extensive research that objectively measure the performance of software delivery and operational stability.

  
  

• Primary Focus: Efficiency and Stability of the Software Delivery Pipeline.

• Scope: Focused on the DevOps technical pipeline.

  
  

• Key Metrics:

  • Deployment Frequency: How often code is released.

  • Lead Time for Changes: Time from code commit to production.

  • Change Failure Rate: Percentage of deployments causing production failures.

  • Time to Restore Service (MTTR): How long it takes to recover from a failure.

• Purpose: To benchmark and improve DevOps capabilities, identifying bottlenecks and areas for technical process optimization. It provides objective data for engineering leaders.

CONCLUSION

• BVSSH is a broad approach providing key dimensions for measuring outcomes of how work is done, including quality, traceability to strategy, flow, risk and control and customer & colleague engagement. BVSSH can be applied to any part of an organization, including software teams. Example metrics are offered, however they will vary based on organisational context. Some of the metrics from DORA or SPACE may be used when the scope relates to software teams

  
  

• SPACE, DevEx and DORA are software specific tools/frameworks that focus on improvement within the system of work for technology delivery

  • SPACE acknowledges the human element in developer productivity and allows a broader lens - measuring aspects of "Happier" (Satisfaction & Well-being) and "Sooner" (Efficiency & Flow) and “Better” (Performance).

  • DevEx is a powerful drill-down into the developer's daily experience, it can be seen as a specific implementation of the SPACE framework. The emphasis of DevEx measurement is to identify factors holding back developer productivity improvement.

  • DORA provides specific metrics for achieving "Sooner" (Lead Time, Deployment Frequency) and "Better" (Change Failure Rate, MTTR) within the engineering context. Whilst this metric is probably the most widely implemented at this stage, organisations now have an opportunity to look beyond this great starting point.

Depending on your context these metrics all lead in the same direction, enabling a focus on efficiency increase through improvements to the system of work. 

Together they represent the philosophical opposite of clock-watching supervisory agents that monitor time-at-desk and “mouse jiggling”.  

BVSSH sets the direction with a scope that is strategic, broad and universally applicable. Within the field of software engineering - DORA, SPACE, and DevEx provide detailed instruments to measure the efficiency of development teams.

You can (and often should) use them complementarily.

References:

1. Schaffner, A. (n.d.). The dangers of confusing activity with productivity. Anna K Schaffner. Retrieved June 10, 2025, from https://www.annakschaffner.com/post/the-dangers-of-confusing-activity-with-productivity

2. Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity. Communications of the ACM, 66(11), 44-49.

3. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations. IT Revolution Press

4. Forsgren, N., Storey, M. A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. L. (2020). The SPACE of Developer Productivity. ACM Queue, 18(1), 1-18.

5. Smart, J., Berend, Z., Ogilvie, M., & Rohrer, S. (2020). Sooner Safer Happier: Antipatterns and Patterns for Business Agility. IT Revolution Press.

The author of this article is a co-author of Sooner Safer Happier (reference 5) and can be contacted via LinkedIn here.