How to use the SPACE Framework to Improve Developer Productivity
SPACE Metrics for
Developer Productivity
Fundamentals of the SPACE framework
The SPACE framework aims to debunk the myths about measuring developer productivity and proposes a healthy and practical way to measure it. The fundamental ideology of the framework is Developer productivity is a function of multiple dimensions and tracking only "one metric that matters” can never represent the actual productivity of your team.
Why should developer productivity matter?
Developer productivity is important not only to measure engineering outcomes but also to the satisfaction of your team members, as satisfaction and productivity are highly correlated. As in any team sport, success of both the team and the individual is important.
What is the right way to measure?
Optimizing only for individual performance would do more harm than good. The key is to find the right balance between individual, team, and organizational success. Any model that reduces developer productivity to a single metric is designed to fail.
Communicate with your team
Developer productivity is perceived differently by developers and engineering leaders. The difference in perceptions can only be eliminated by having a conversation on the intention and importance of tracking developer productivity. And also eliminates reservations like, Is this the number that decides our appraisals? Or are we doing this because the leadership doesn’t trust us to get the job done?
Productivity ≠ Formula
Engineering is both a science and an art, and measuring LOCs only is like counting the brush strokes by an artist irrespective of the outcome. Rather than looking at metrics to equate to performance, one should look at SPACE metrics to identify bottlenecks and improvements for the development team. Developer productivity was never a formula, nor it will ever be. It’s a data-backed ideology to truly care for your developers and engineering outcomes at the same time.
SPACE metrics span across these five dimensions: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow. It’s best to measure developer productivity with metrics spanning at least three out of these five dimensions.
“Similar to team sports, success is judged both by a player's personal performance as well as the success of their team. A developer who optimizes only for their own personal productivity may hurt the productivity of the team.”
/01. Satisfaction and well-being
The biggest source of fulfillment for developers is by doing development that makes a difference. And to ensure a healthy working environment for your team it's important to be mindful of the stress caused by the workload and have measures in place to mitigate it before it's too late. It’s absolutely crucial to include this dimension of SPACE metrics when tracking developer productivity.
Exhaustion is caused by excessive workplace stress and often when the team is over-committing. Looking at the trends in developer engagement with team activities, and whether the developer is working long hours or over the weekend can help you be proactive in detecting signs of burnout and take preventive action before it happens.
The biggest satisfaction factor for a developer is when his/her committed work gets completed and makes a difference to customers. Being involved in developing new features and working on newer technologies is also one of the contributors. Measuring task completion percent, code deployed percent and work distribution are great ways to track developer satisfaction.
Retention rates are a great indicator of happiness for your team. Also tracking referrals help you understand whether the developers recommend your team to others. The best indicator of satisfaction is when your developers are staying for longer and persuading others to join your team as well.
/02. Performance
SPACE framework suggests the best way to track performance is by measuring outcomes rather than output. Often the outcome of individual contribution is dependent on the type of work that is assigned to the individual. Thus measuring outcomes at a system level can help you understand the performance of your team.
A high number of iterations and reworks to complete the same task signals a bottleneck in the process, often due to a lack of clarity on what needs to be developed. This can delay your time to value and cause delivery of features to slip. Measuring the rework factor and understanding how often your team can deliver on the committed timelines are good indicators of performant processes and teams.
The absence of bugs is a great indicator of the quality of work and the productivity of your team. The two stability DORA metrics change failure rate (CFR) and mean time to recover (MTTR) help to measure how frequently your system encounters a failure and how long it takes to recover from it.
Having a bug-free and highly performant system that your customers don’t use is a red flag. This may not necessarily stem only from the dev teams’ performance, however including factors like customer satisfaction and usage helps you keep your team focused on what really matters.
/03. Activity
While tracking developer activity across the SDLC provides some insights into productivity and efficiency, focusing solely on the activity dimension of SPACE metrics won’t give a complete picture of true developer productivity.
A summary of development activities like story points shipped, pull requests merged, code reviews completed, and bugs resolved to help you understand the efficiency of your team across the different phases of your development lifecycle.
Designing is a part of the development process and including this as a part of the SPACE metrics helps in capturing individuals’ efforts in designing the systems and maintaining relevant documentation related to it which helps in faster and asynchronous knowledge sharing within the team.
The number of deployments done by the team, and the number of production incidents/failures encountered are good examples of metrics that help in understanding the activity dimension.
“Developers often say that productivity measures aren't useful. This may come from the misuse of measures by leaders or managers, and it's true that when productivity is poorly measured and implemented, it can lead to inappropriate usage in organizations.”
/04. Communication and collaboration
This dimension of SPACE metrics is crucial to capture the aspect of how well the team can collaborate and whether there is an optimal flow of information amongst the team members. A team that communicates better and has a culture of transparency is bound to be more productive as team members know about the priorities and what others are working on which makes it much easier to coordinate dependencies.
How quickly a team responds to review requests and the time it takes for a piece of work to be integrated and deployed to production is a clear indication of how efficiently the team communicates and collaborates. Tracking response time for pull requests and overall cycle time helps you understand how efficiently the team collaborates in each stage and also easily pinpoint the areas that need your attention.
Understand how individuals in your team collaborate with which and how many team members, often these trends will help you identify knowledge groups or silos within the team. Silos also exist if individuals only contribute to specific parts of the system and others are unaware of it. A higher knowledge distribution within the team is indicative of efficient collaborative practices and a great metric to track this dimension of the SPACE framework.
The time it takes for new team members to make their first meaningful contribution is indicative of how well the team can help a new member understand the existing system and contribute. Accessibility and availability of necessary documentation can help decrease the time for the new member to start being productive.
/05. Efficiency and flow
This dimension of SPACE metrics attempts to capture how well work is done across the team and whether development activities continue without interruptions. Flow tries to capture how many hours can developers dedicate to uninterrupted work and also how swiftly can a piece of work, flow through different processes. DORA metrics do a great job of capturing the flow metrics at a team level.
Deployment frequency and Change lead time help you capture the overall efficiency and speed of your processes. The higher the deployment frequency and the lesser time it takes for a commit to reach production, the better efficiency and flow you have across your different engineering processes.
Understanding what percent of the team’s work gets wasted or deprioritized due to ad-hoc tasks is a great measure of understanding the efficiency of your development lifecycle. Frequent context switches can significantly reduce productivity. It's crucial to minimize ad-hoc tasks and limit constant context switching to enhance development efficiency.
Capturing how much uninterrupted focused time team members get is a good indicator of developer productivity. Often high number of parallel tasks and frequent meetings across the day are reasons leading to higher breaks in the state of flow, which leads to poorer outcomes and increased stress and burnout.
“The most important takeaway from the SPACE framework is that productivity cannot be reduced to a single dimension (or metric!).”
Misconceptions about developer productivity
Read answers to the most common misconceptions and myths about tracking developer productivity.
Does tracking developer productivity mean I don't trust my team and want a way to measure it?
Developer productivity is not a “taboo”. The reason for running away from developer productivity is that leaders have often represented it as metrics that are easy to track, and not the ones that make more intuitive sense. When developer productivity is tracked for the right reasons it becomes a motivator for the team, where everyone understands that optimizing the right metrics ultimately leads to a happier and more satisfied development team.
Is developer productivity only for engineering managers and leaders?
Not at all. The way developer productivity has been defined in the past is the primary reason for developers’ perception that “productivity measures aren’t useful”. However, developer productivity when measured correctly can also be used by the developers to measure themselves and understand areas of improvement. Given there is a high correlation between productivity and happiness, it becomes even more important for developers to track this.
Are these the only SPACE metrics to track?
Historically developer productivity is either something the leaders run away from or reduce to one metric, which is clearly the worst way to deal with it. The SPACE framework clearly sets out the areas that matter and gives examples of metrics that could be tracked in each dimension. However SPACE metrics are not a fixed set of metrics to track, but more like guidance for teams to select metrics that make the most sense for them.
Can I start with a few metrics and then incrementally track others?
The underlying ideology of the SPACE framework is, you shouldn’t say Developer productivity = Story points shipped BUT when you say Developer productivity = Story points shipped AND PR cycle time AND Customer satisfaction it completely changes the way you track developer productivity. Starting small is absolutely okay, however, do ensure you track one metric across at least three out of the five dimensions.
We Integrate with the Tools
you Trust
Look at the best engineering analytics platform that helps you drive engineering excellence and better business outcomes
Explore All Integrations
Don't Take our Word for it.
See AnalyticsVerse in Action for Yourself
Start Your Free Trial
No Credit Card Required
Upto 28 days free trial
Upto 1 year historical data
All features included