About the Frameworks

SPACE Framework

The SPACE Framework is a methodology used to measure and improve the productivity of software developers and teams. This framework is divided into five main dimensions, each addressing crucial aspects of the software development process.

	SATISFACTION & WELL-BEING	PERFORMANCE	ACTIVITY	COMMUNICATION & COLLABORATION	EFFICIENCY & FLOW
INDIVIDUAL	One person
	Developer satisfaction	Code review velocity	Code review comments	Satisfaction with work	Code review timing
	Retention		Commits		Lack of interruptions
	Perception of code reviews
	Satisfaction with work
TEAM OR GROUP	People that work together
	Developer satisfaction	Code review velocity	Work shipped	PR merge times	Developer acceleration
	Retention			Meeting quality	Handoffs
SYSTEM	End-to-end system
	Satisfaction with engineering system (e.g., CI/CD pipeline)	Code review	Deployment frequency	Knowledge sharing, discoverability (quality of documentation)	Code review timing
		approval rate			Velocity through the system
		Time to approve code reviews
		Reliability (uptime)

Satisfaction & Well-Being

This dimension capture how fulfilled developers feel with their work, team, tools, or culture. Measuring satisfaction and well-being can be beneficial for understanding productivity and perhaps even for predicting it. Metrics include:

Developer Satisfaction: How satisfied developers are with their work.
Retention: The ability to retain developers in the team or company.
Perception of Code Reviews: How developers perceive the code review process.
Satisfaction with Work: The extent to which developers feel fulfilled and happy with their daily work.

Performance

This dimension capture the outcome of a system or process and is often the sum of many developers' contributions. Metrics include:

Code Review Velocity: The speed at which code reviews are completed.
Code Review Approval Rate: The percentage of code reviews that are approved.
Time to Approve Code Reviews: The time it takes to approve a code review.
Reliability (Uptime): The availability and stability of the system.

Activity

This dimension capture a count of actions or outputs completed in the course of performing work. Developer activity, if measured correctly, can provide valuable but limited insights about developer productivity, engineering systems, and team efficiency. Metrics include:

Code Review Comments: The number of comments made during code reviews.
Commits: The number of commits made.
Work Shipped: The amount of completed and shipped work.
Deployment Frequency: The frequency of software deployments.

Communication & Collaboration

This dimension capture how people and teams communicate and work together. Software development is a collaborative and creative task that relies on extensive and effective communication, coordination, and collaboration within and between teams. Metrics include:

Satisfaction with Collaboration (e.g., CI/CD pipeline): How satisfied developers are with collaboration processes, such as CI/CD pipelines.
PR Merge Times: The time it takes to merge pull requests.
Meeting Quality: The effectiveness and efficiency of team meetings.
Knowledge Sharing: The effectiveness of documentation and the ease of finding information.

Efficiency & Flow

This dimension capture the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system. This can include how well activities within and across teams are orchestrated and whether continuous progress is being made. Metrics include:

Code Review Timing: The speed at which code is reviewed.
Developer Productivity: The ability of developers to complete tasks efficiently.
Lack of Interruptions: The amount of uninterrupted work time.
Developer Acceleration: The ability of developers to speed up their work without loss of quality.
Handoffs: The efficiency of transitions or handoffs between different phases of development or between different developers.

Frameworks: Road to epic teams

Dora Metrics

DORA and Others

The following table provides a detailed overview of key performance metrics used to evaluate the efficiency, deployment performance, and quality of software development processes. These metrics are categorized into three main areas: Efficiency, DORA (DevOps Research and Assessment), and Quality and Predictability.

Category	Metric	Elite	Good	Fair	Needs Improvement
Efficiency	Merge Frequency (per dev/week)	> 2	2 - 1.5	1.5 - 1	< 1
	Coding Time (h)	< 0.5	0.5 - 2.5	2.5 - 24	> 24
	PR Pickup Time (hours)	< 1	1 - 3	3 - 14	> 14
	PR Review Time (hours)	< 0.5	0.5 - 3	3 - 18	> 18
	Deploy Time (hours)	< 3	3 - 69	69 - 197	> 197
	Cycle Time (hours)	< 19	19 - 66	66 - 218	> 218
DORA	Deployment Frequency (per service)	> 1/day	> 2/week	2/week	< 1/week
	Change Failure Rate (%)	< 1%	1% - 8%	8% - 39%	> 39%
	MTTR (hours)	< 7	7 - 9	9 - 10	> 10
Quality and Predictability	PR Size (code changes)	< 98	98 - 148	148 - 218	> 218
	Rework Rate (%)	< 2	2% - 5%	5% - 7%	> 7%
	Refactor Rate (%)	< 9%	9% - 15%	15% - 21%	> 21%
	Planning Accuracy (%)	> 85%	85% - 60%	60% - 40%	< 40%
	Capacity Accuracy (per sprint)	Ideal Range 85% - 115%	Under Commit above 130%	Potential Under Commit 116% - 130%	Potential Over Commit 70% - 84%

Efficiency Metrics

Merge Frequency: This metric measures the frequency at which code changes are merged into the main branch. Higher merge frequencies indicate a more active and potentially more productive development process, where changes are integrated and tested regularly.

Elite: Greater than 2 merges
Good: Between 2 and 1.5 merges
Fair: Between 1.5 and 1 merge
Needs Improvement: Less than 1 merge

Coding Time: This metric tracks the amount of time developers spend writing code. Lower coding times can indicate higher efficiency, while excessively long coding times might suggest potential inefficiencies or complexities in the development process.

Elite: Less than 0.5 hours
Good: Between 0.5 and 2.5 hours
Fair: Between 2.5 and 24 hours
Needs Improvement: More than 24 hours

PR Pickup Time: This metric measures the time it takes from when a pull request is created until it is picked up for review. Faster pickup times suggest a more responsive review process, which can lead to quicker integration and feedback cycles.

Elite: Less than 1 hour
Good: Between 1 and 3 hours
Fair: Between 3 and 14 hours
Needs Improvement: More than 14 hours

PR Review Time: This metric measures the duration of the code review process from when a pull request is picked up until the review is completed. Shorter review times can improve development speed and reduce bottlenecks in the workflow.

Elite: Less than 0.5 hours
Good: Between 0.5 and 3 hours
Fair: Between 3 and 18 hours
Needs Improvement: More than 18 hours

Deploy Time: This metric tracks the total time required to deploy code changes to production. Efficient deployment processes reduce downtime and allow faster delivery of new features and fixes.

Elite: Less than 3 hours
Good: Between 3 and 69 hours
Fair: Between 69 and 197 hours
Needs Improvement: More than 197 hours

Cycle Time: This metric measures the entire duration of a development cycle from the initiation of a task to its completion. Shorter cycle times can indicate a more efficient development process and quicker delivery of value to users.

Elite: Less than 19 hours
Good: Between 19 and 66 hours
Fair: Between 66 and 218 hours
Needs Improvement: More than 218 hours

DORA Metrics

Deployment Frequency: This metric measures how often code changes are deployed to production. Higher deployment frequencies can indicate a more agile and responsive development process.

Elite: More than once per day
Good: More than twice per week
Fair: Twice per week
Needs Improvement: Less than once per week

Change Failure Rate: This metric tracks the percentage of deployments that result in failures requiring immediate fixes. Lower failure rates indicate a more stable and reliable development process.

Elite: Less than 1%
Good: Between 1% and 8%
Fair: Between 8% and 39%
Needs Improvement: More than 39%

MTTR (Mean Time to Recovery): This metric measures the average time required to restore service after a failure. Shorter MTTR values indicate a more resilient system capable of quickly recovering from issues.

Elite: Less than 7 hours
Good: Between 7 and 9 hours
Fair: Between 9 and 10 hours
Needs Improvement: More than 10 hours

Quality and Predictability Metrics

PR Size: This metric tracks the size of pull requests based on the number of code changes. Smaller PR sizes can lead to more manageable and quicker reviews, enhancing code quality and collaboration.

Elite: Less than 98 changes
Good: Between 98 and 148 changes
Fair: Between 148 and 218 changes
Needs Improvement: More than 218 changes

Rework Rate: This metric measures the proportion of code that needs to be revised or reworked after the initial implementation. Lower rework rates indicate higher code quality and more effective initial development efforts.

Elite: Less than 2%
Good: Between 2% and 5%
Fair: Between 5% and 7%
Needs Improvement: More than 7%

Refactor Rate: This metric tracks the amount of code that is refactored to improve its structure or performance. Lower refactor rates suggest that the code is well-written initially, reducing the need for significant modifications later.

Elite: Less than 9%
Good: Between 9% and 15%
Fair: Between 15% and 21%
Needs Improvement: More than 21%

Planning Accuracy: This metric measures how accurately planned tasks are completed within a given timeframe. Higher planning accuracy indicates better forecasting and execution capabilities.

Elite: More than 85%
Good: Between 85% and 60%
Fair: Between 60% and 40%
Needs Improvement: Less than 40%

Capacity Accuracy: This metric assesses the precision of capacity planning for each sprint. Maintaining an ideal range ensures that teams are neither overburdened nor underutilized, leading to more sustainable productivity.

Elite: Ideal range between 85% and 115%
Good: Under commit above 130%
Fair: Potential under commit between 116% and 130%
Needs Improvement: Potential over commit between 70% and 84%