agile team performance metrics

Four Agile Team Tracking Metrics in Action

Andrew Zola
Storyteller
Andrew Zola on Linkedin

If you conduct a Google search on how you can measure a software project during a build cycle, you will find a ton of them. But most of these metrics are completely useless. While they may all sound pretty cool, they offer little to no value.

The sad reality is that most companies are fans of them and have grown to expect them. Whether you like it or not, you will have to use them, too.

To help your Agile/Lean team improve while making your boss or client happy, we have identified a few metrics you can use to get actionable value. There is more than one metric as you have to avoid a myopic approach to tracking agile teams.

At the same time, it’s important not to overdo it as our minds can only handle a handful of concepts at any given time. Furthermore, you also have to avoid using different metrics in different parts of the organization as it can derail your efforts to align all departments.

So what should you focus on?

1. Agile Cycle Time Metric

A software development team’s productivity can be measured accurately in short cycle times. It has to be measured from start to finish automatically by using an agile lifecycle tool that best suits you.

Additionally, you can also measure the physical task board to derive some valuable data. A spike in the cycle time will mean that the team is getting started on a new project. While going through several organizational changes, increase ramp-up time as the team starts to get more comfortable with the task at hand.

2. Escaped Defect Rate

The escaped defect rate metric can be used to measure the connection between the development team and customer satisfaction. If you have a high escaped defect rate, you’re going to have a lot of customers that aren’t satisfied with your product (even though it might pretty amazing).

If the defect rate is low, then the chances of having a satisfied user base will be pretty high (and they will probably stick with the product). This can be done by keeping track of the number of issues that popped up after the product was delivered to the end user.

It will be an ongoing process until the story is complete, so you will have to focus on how it’s executed. It’s also a better approach than focusing too much on tracking in-progress defects.

The escaped defect rate graph will show a reasonably representative curve when the team has moved on to cross-functional roles and automated testing. For example, you will see a dramatic drop in defects after the product release when the whole team is jointly responsible for the product’s quality and the story with a higher focus on automated testing.

3. Plan-to-Do Ratio

If the team commits to 40 stories and then delivers 12, the probability of the product owner getting what they want will become pretty slim. But if the team is delivering on 90% of the stories, then the product owner also has a 90% chance of getting what they asked for.

It’s a simple measurement that documents the amount of work the team commits to doing at the beginning of the sprint versus how much they actually managed to complete at the end of the sprint.

By generating a plan-to-do chart, you can easily see when a ScrumMaster left a team, when a new one came in, how the team got used to him or her, and how things picked up or got worse.

4. The Health/Happiness Metric

The final metric will put the other three into (better) perspective. Happiness or health will indicate what’s going on within your agile team.

For example, if the three previous metrics all indicate that things are going well but the happiness metric is low, then your team is probably burning out (rapidly).

Furthermore, it will also show what kind of impact the ScrumMaster is having over the team’s overall health. This graph will also reflect the company and the product churn’s impact on the team.

So start making this a part of your sprint retrospectives and start each retrospective with your team members providing happiness scores on whatever scale you choose. By keeping track of these numbers from sprint to sprint, you will start to see patterns and trends that can help you improve the general health of the team.

What metrics do you use to measure your agile team’s performance? Please share your thoughts in the Comments section below.