Even though practical skills and knowledge of specific programming languages, tools and technologies is the key to landing a full-time job as a software developer, there is another valuable indicator that in many ways can be viewed as a presupposition for success in this profession: productivity.
Productivity measurement is something all professional software developers need to understand and take into account as performance metrics are inherently important for any software development team in today’s business environment.
Why does your productivity as a developer matter?
In the era of Agile development, DevOps and shrinking software release cycles, when developers need to ship new versions of products as quickly as possible, companies use multiple different productivity metrics to evaluate the performance of individual programmers and a team as a whole.
Looking at this from a developer’s point of view, performance measurement can serve a number of valuable purposes, helping you to track the progress of your programming skills, which would allow you to achieve consistent professional growth.
Highly productive coders are the ones who end up receiving jaw-dropping salary offers and get to work on the most exciting projects. But even if you’re not exactly a high achiever and just want any job in software development and to be reasonably successful in it, you still need to have at least a basic understanding of performance indicators and how they are used to measure the productivity of your input at work.
Which is what we are going to talk about today.
Software development productivity measurement metrics
What are software development productivity metrics?
Software development metrics are the areas of programming work where quantitative measurements can be applied in order to track the performance, quality of work and productivity of a developer. Every productivity metric is based on taking data from the development process and using it to measure productivity.
As pretty much nothing related to software development is easy and straightforward, you could say that measuring programming productivity is also quite inconsistent and fragmented across the industry. Or, simply put, various teams and companies can use completely different performance indicators and approach this issue from a number of angles.
So you don’t need to bother with learning each and every metric that may be used by software development teams. But it is certainly advisable to know and understand the most popular and common metrics used in the software development industry in general.
What types of software development productivity metrics are there?
Naturally, there are multiple different productivity metrics that approach measuring performance on various levels and angles. Here are the most common types of such productivity metrics:
- Formal size-focused metrics.
These metrics are focused on measuring the size of a programmer’s work outcome, such as lines of code (LOC), code instructions length, code complexity, etc. These metrics are increasingly considered to be outdated in today’s software development industry.
- Time and function-focused productivity metrics.
There is a selection of traditional productivity metrics used in waterfall software development, such as active days, the scope of functionality shipped in a set period of time, code churn rates, number of tasks assigned, etc.
- Agile development process metrics.
Agile development process metrics, such as sprint burndown report, velocity, lead time, cycle time and others, are probably the most commonly used metrics among software development teams today. We will talk about Agile metrics in more detail later in the article.
- Operational analytics metrics.
This set of metrics is focused on measuring software performance in its current production environment. Mean time between failures (MTBF), mean time to recover (MTTR), and application crash rate are the most used metrics here.
Software testing has its own set of metrics to measure the quality of system testing, such as percentage of automated tests, code coverage, etc.
- Customer satisfaction metrics.
Finally, the ultimate metric for any piece of software is end customer experience, and there is a whole set of metrics for that as well, such as customer effort score (CES), customer satisfaction score (CSAT), net promoter score (NPS) and others.
Agile software development metrics
As you can see, it is quite easy to get lost in all the intricacies of software productivity metrics. The only ones a regular software developer should be well-familiar with, however, are the Agile metrics, commonly used by software development teams today as standards of team productivity measurement across different parts of the software development life cycle.
Let’s list the main and most commonly used Agile metrics.
1. Sprint Burndown.
Sprint Burndown reports is one of the key metrics for agile scrum development teams. As in agile the development process is organized through time-bound sprints, Sprint Burndown is used as a way of tracking the completion of tasks during a sprint. Hours or story points are used as a unit of measurement. The goal is to achieve consistent progress and deliver work in line with initial projections. Sprint Burndown helps teams to measure the pace of work and adjust it when needed.
2. Team Velocity.
Velocity is another key indicator, which is also based on hours or story points as a unit of measurement. It measures the average amount of work a team completes during a sprint and is used for estimation and planning throughout all the project. Tracking velocity is important to make sure the team delivers consistent performance.
3. Story Points.
On an individual development team member’s level, story points is a valuable metric, as the size of the stories a programmer delivers during each release is an indicator of this coder’s productivity.
4. Cycle Control Chart.
Measures the total time from the moment when the work on a task or another backlog item has started until its completion. Allows to track and control cycle times delivering more predictable results.
5. Throughput and Value Delivered.
Project managers analyze tasks assigned to developers and assign value to them. This metric is then used to measure the throughput of the team or, in other words, the amount of value-added work done.
6. Code Churn.
Code churn is another metric that is worth mentioning as it is used for measuring both the productivity of a team as a whole and to track the performance of individual programmers. Code churn measures how often a developer removes or makes changes in previously added lines of code, and what percentage of previously written code ends up changed or thrown away.
Finally, to add some perspective, a few quotes on the matter by experienced software development industry professionals.
“I do hope you're not looking to "compare" your metrics with some kind of standard or even with the performance of another team in another company. Everywhere that I have worked has had unique variations in their definitions of story points, velocity, hourly estimates, tasks, etc. that really would make it nearly impossible to compare the performance of one team from one company directly with that of another team at another company,” Cliff Gilley, former Technical Product Manager and Agile Coach, noted
“I'm a little leery of metrics when it comes to guiding team performance. Once you pay attention to just one or two variables it becomes very easy to fall into (intentionally or otherwise) gaming the metric and fool yourself that you're improving - when all you're doing is improving the metric. For example, metrics based on velocity can "improve" by the team moving to smaller stories (less work per-story - so more stories completed - so velocity goes up). That might be a good thing if the stories are useful user stories that deliver smaller increments of business value. That might be a bad thing if the stories become smaller and more "technical" tasks that don't deliver real value by themselves,” Adrian Howard, another industry professional, said
“When working in a pull-based system, I value throughput and cycle time. The first gives me general info about our team's capacity, and over time can become a very powerful predictive measure. The second is helpful as a general gauge of our pipelines' efficiencies. If cycle time is high, it's time to start looking at the pipeline, because there's a constraint that we can probably work toward easing/exploiting. But metrics are just tools. Don't get lost in them, and certainly don't start planning toward a specific metric. Think about what you are making as a team and how you naturally work, then build the system around the people. The metrics should help you see how your system is supporting everyone's work. Or not,” Dave Cerra, a video game development producer, concluded