Team Metrics I Use 📈

Jul 09, 2021 5:44 pm

Hi there,

You might notice this email is coming to you a little later than normal. Its just one of those days. I'm taking my son camping this weekend so I've been getting all the gear ready for that.

Before I go further, thanks for the people who volunteered to take my class and provide feedback. If you missed out you can contact me and we'll work something out.

I was working recently with someone in a senior role who was getting frustrated at his dev team. So he called a meeting to set expectations. Some of those included:

  • Escalate issues to him immediately
  • Complete every item in the sprint at all costs
  • Attend each meeting as they are all mandatory

Now, this ought to make you cringe. See, each of these does more for making the senior person feel like things are orderly than improving anything. The senior person for example ignored all escalations, never attended the mandatory meetings, and creates work items for the team, and doesn't tell them anything about it.

This style of feeling like you have tight control of things often inhibits performance than correcting it, but there's an art to letting go.

After I set up a team I like to use a handful of metrics and measures to see how things go. I don't use these to compare individuals or compare across teams.

Cycle Time

Almost every tool tracks this for you, but what I'm looking for here is the trend of cycle times. Even if the work is complex, their process rarely is, so you can observe some stability in cycle time. A huge spike is something to go find out about with a question like, "What's different about this?"

Defect Rates

The pressure to build faster and faster is part of our industry and the easiest thing to drop is quality. Got contractors or consultants? Internally there is almost a guarantee someone in there is saying to them, "The client doesn't pay you for tests."

So I keep an eye on the defects that escape development compared to how many work items they complete. This ratio is a defect rate. I then also track how many defects they close. This gives me a good high-level overview of how effective the team is at keeping their quality up.


This one is subjective and one I keep an eye on through 1:1s. I keep an eye on how many conversations are oriented towards the better future ahead vs the insurmountable problems around us. The former is an indication that things are good enough, and the latter is not.


Here's an odd one, how many times does a team make a suggestion about the direction of the product, marketing, sales, or so on? Great teams feel a sense of responsibility for everything, and as the team gets stronger their willingness to make suggestions on what they think makes a great product will increase.

It's a little interesting that we focus so much on development teams and often create a singular product owner. We recognize the value of multiple developers helping each other but tend to isolate the product person. While some companies have a rich and mature product side, all too often it relies on a singular person.

Anyway, these metrics and indicators have served me well over the years and are easy to start with. The bigger the challenges the team takes on, the more "Hard to move" metrics we begin to look at.

Have a great weekend!