Are you a team lead, tech lead, or other engineering leader? If so, I’m sure you’re always trying to improve your team’s productivity. One of the ways you can do that is by tracking and improving the right set of agile metrics.
Engineering metrics abound, and the vast majority aren’t worth your time. Bad metrics can bring morale down, create perverse incentives, and cause the best engineers to quit. How do you separate the wheat from the chaff?
In this post, we’ll cover the five agile metrics that are worth your time. For each metric, we’ll cover what it is, why it’s important, and why it’s considered an agile metric. Before concluding, we’ll warn you about some metrics you definitely shouldn’t be using. Let’s get started.
Agile Metrics: Five You Should Care About
Without further ado, here are the metrics you should adopt.
1. Cycle Time
Cycle time is arguably the most important engineering metric you can track.
What It Is
Cycle time measures how long it takes to complete a piece of functionality from the start of the work until it’s in production. Obviously, you want to beat your competitors to market, which means cycle time is a metric you want to keep down.
Why It Matters
A low cycle time indicates a lot of good things:
- The team is fast in implementing, testing, and delivering features
- There’s great communication inside the organization, and requirements are being properly communicated
- There aren’t too many bugs since the team can focus on delivering new features quickly
- You’re getting to market fast, ensuring more revenue and higher customer satisfaction
Why It’s an Agile Metric
The agile manifesto, both in his values and principles, stresses the importance of working software as a measurement of progress. Getting real, working software into customers’ hands is real progress, and doing it more rather than less often is even better. A low cycle time ensures that’s happening.
2. Code Churn (AKA Rework)
Code churn is also called rework. As you’ll see, it’s a valuable metric. It can help you assess how risky certain areas of the codebase might be. Also, it can uncover some unhealthy trends in your development process.
What It Is
Code churn measures how often a given software artifact—a class, a function, etc.—is changed after it’s first written. The higher the number of edits, the higher the churn.
Why It Matters
Knowing how much code churn you have can help you discover issues in your codebase and development process.
For instance, a high rework rate might indicate that developers aren’t receiving clear requirements before implementing features, which is a communication and process problem. It might indicate design or architectural issues in your app, which makes it more likely that developers will introduce defects that need fixing afterward.
Also, frequently edited code is more likely to have defects introduced due to sheer probabilities. Thus, you can use your rework rate to assess the likelihood that a certain area of the code is defective, which can be useful in strategies like risk-based testing.
Why It’s an Agile Metric
One of the agile manifesto principles reads, “Simplicity—the art of maximizing the amount of work not done—is essential.” Keeping a low rework value is totally compatible with this principle since it avoids waste.
3. Technical Debt Ratio
Our third metric relates to the concept of technical debt, i.e., deliberately taking a shortcut when designing or implementing a feature to accelerate time to market.
What It Is
A technical debt ratio compares the effort of fixing (remediating) a bad codebase with the effort to build it from scratch. It essentially indicates how much interest the technical debt has accrued.
Why It Matters
A high technical debt ratio indicates that you have a lot of technical debt, which is bad enough by itself. It also suggests that fixing the codebase might not be worthwhile in the first place.
Keeping the technical debt—and, by consequence, the technical debt ratio—as low as possible ensures that developers will be able to spend their time mostly on delivering new features.
Why It’s an Agile Metric
It all boils down to avoiding waste and ensuring that you frequently deliver working software to the customer. Time spent paying off technical debt isn’t time spent creating new functionality.
4. Defect Escape Ratio
You want to find out about bugs before they make it to production and this metric measures that.
What It Is
Defect escape ratio tells you how many defects were found in production compared to those found before production.
Why It Matters
Defects are easier to fix the earlier you find them. Bugs that make it to production harm the user experience, bring customer satisfaction down, and can even result in system outages.
Why It’s an Agile Metric
You want to deliver working, stable, bug-free software to your customers as quickly and frequently as possible, so you don’t want defects to escape.
5. Code Coverage
Code coverage is an important but often misunderstood engineering metric.
What It Is
Code coverage indicates how much of your codebase is covered by automated tests—unit tests in particular.
Rather than a single metric, code coverage comes in a few different types:
- Line Coverage. This is the most basic form. It measures the ratio of lines of code covered by tests.
- Statement coverage. This is slightly different than line coverage because in many languages a statement can span several lines and because a line can contain more than one statement.
- Branch coverage. This is arguably the best type of coverage because it measures the ratio of logical branches covered by the tests.
Why It Matters
A suite of unit tests should act as a safety net for your codebase. But for that to happen, engineers must trust the tests, which requires a high degree of coverage.
While high coverage doesn’t ensure quality, it is the bare minimum, and a comprehensive test suite can bring you some peace of mind.
Why It’s an Agile Metric
Unit testing is intrinsically connected to agile because it’s one of the pillars of CI/CD (continuous integration/continuous deployment), which ensures that you deliver software to the customer frequently and safely. Code coverage is a good measure of the progress of your unit testing strategy.
Metrics to Stay Clear Of
Before wrapping up this post, we’ll briefly mention some metrics you’d be wise to avoid—or at least to use with extreme caution.
Agile Velocity
Agile velocity is a dangerous metric for software teams. The metric itself has its value, but engineering leaders often abuse it and use it for purposes it wasn’t meant for:
- Comparing teams
- Estimating delivery dates
- Evaluating performance
Story points—and, by consequence, velocity—only make sense for capacity planning inside the boundaries of a single team.
Lines of Code
Lines of code is a terrible metric, especially if you assume more lines of code are better. Code is a liability, not an asset, and the number of lines don’t necessarily correlate with effort spent.
Let’s allow this metric to die.
Individual Metrics in General
Metrics focusing on the individual tend to be easily gameable and create perverse incentives. Things like the number of commits per developer, the number of pull requests per developer, the number of code reviews made, and so on usually lead to terrible outcomes. Let’s abandon those too.
Agile Metrics: Measure Your Team Humanely
Some people think metrics are anti-agile. They argue that employing metrics is a sign of the old style of managing, that it goes against the developer autonomy crucial to the agile ethos.
Guess what: measuring developers doesn’t mean you have to adopt a tyrannical leadership style.
Individual and easily gameable metrics destroy your team’s morale, especially when they’re coupled with desirable outcomes. They foster competition and create resentment between developers.
On the other hand, great metrics allow you to improve your team’s productivity without destroying its culture. They can give rise to shared goals—i.e., bring the average cycle time down—which favors the creation of strong bonds between team members.
Thanks for reading, and until next time.
