How do you determine whether you’ve hit one of your goals or not? You have to measure it in some way. A Key Performance Indicator (KPI) is a measurable value that businesses use to determine the success or failure of various campaigns and business objectives.
In previous articles, we’ve looked at measuring individual developer productivity and how to measure team based productivity.
Pro Tip: Code faster with TextExpander
TextExpander makes it easy to save commonly-used code snippets, documentation comments, and more — then insert them anywhere you type with a simple shortcut or inline search.
Click here to learn more.
These have value – productive people and teams are generally happier and more effective. However, metrics tied to specific business objectives are much more powerful; they directly link development effort to business value. It is these types of objectives we want to talk about today.
The Disconnect Between Business and Software Development
Development teams grow organically and rarely start with a well-defined set of KPIs governing their ongoing review.
At some point, setting KPIs will become mandated. When that happens, the issue you will often face is that upper management rarely understands the specific issues that impact a development team. On the other hand, development teams don’t always appreciate the rationale behind many business decisions.
With this in mind, we want to share 6 essential KPIs for software development teams. These can act as conversation starters when setting KPIs for your organization.
1. Writing Stable Code
Writing stable code refers to creating changes to the product that don’t harm the rest of the business.
If releasing a new feature breaks an existing feature, that can be bad for business. To avoid that, aim for stable code. Stable code is calm code. Plus, when the team isn’t reacting to the negative upshot of an unstable codebase, they can focus on developing new features.
You could word the KPI for writing stable code as:
“Less than 2% of code deployed for the year should result in downtime of the application.”
2. Writing Testable Code
When we talk about writing testable code, we mean both writing code that is easy for an automated system to test and also writing those tests. The tests act like documentation so that changes from a developer will quickly show any errors.
This software development KPI is also important to the business because it can serve as a measure for how easy it is to onboard new developers. A well-tested codebase makes things much easier to track when adding a new person to the team.
An example of a KPI for writing testable code is:
“By the end of the quarter, our codebase should have code coverage of at least 97%.”
3. Working on Code Churn
Code churn refers to how often code changes over time. While it is a natural part of the development cycle, code churn should be minimized where possible.
The less code that needs to change to accommodate a new feature the better. This measure is also a proxy for how easy change is in the system. The easier change is, the less risk is involved. Management loves mitigating risk.
An example of a KPI encompassing code churn is:
“The last two days of every sprint should see code churn at 10% or less.”
4. Writing Simple Code
Writing simple code involves writing in such a way that the intent is clear to both other developers and the machines running the system.
The simpler the code, the easier it is to test and change. Whenever you have a new developer come on board, it takes them time to learn the new code, reduce that time by having your codebases written simply.
One metric of code simplicity is cyclomatic complexity, this measures the number of independent paths your code might have to take – the fewer, the better.
There are several tools for measuring cyclomatic complexity. For example, in the Ruby programming language, a popular tool is Rubocop
Here is an example of a KPI that incorporates writing simple code:
“No code should make it into code review with a cyclomatic complexity higher than what Rubocop suggests for this project.”
5. Sharing Knowledge
All of our KPIs for software development teams so far have been technical, but developers don’t spend all day writing code. Their KPIs should reflect this. When we talk about sharing knowledge, we mean either developers sharing what they know with other developers or with the broader team.
The more sharing that is done, via code documentation, collaborative meetings, sharing of new things learned or articles written, the less management will worry that only a few key people within the team are gatekeepers to valuable knowledge.
An example of a KPI written with sharing knowledge in mind:
“Once a month you share an article with your team describing a part of the development process in our company.”
6. Supporting Each Other
Related to sharing knowledge is supporting people within the immediate and broader team. Developers are useful for more than writing code. KPIs built around being good citizens of the company help to integrate the development team with the company.
Great work doesn’t happen in silos. The more that different teams can work together, the better the overall product will be.
Supporting each other can take many forms, such as:
- Being present in meetings and using active listening
- Making sure that suggestions from other teams are given appropriate consideration
- Communicating well with rest of the company
One KPI that would include supporting each other could be written like:
“Each week you have sent at least one email to the sales team sharing what work you’ve done and seeing if they have any feedback.”
What Software Development KPIs Does Your Team Use?
Do you work on a development team? We’d love to hear what KPIs you’ve worked with before. Please share them in the comments below.
Not able to play the video? Click here to watch the video
