Software project metrics are often controversial. The management team needs to measure the performance of the development team. The metric of choice is often a binary one — did they hit the target date or not. Good managers know that merely hitting dates is almost meaningless. What about quality, reliability, security, and the wow! factor?
Agile development teams often use velocity as an internal performance metric. Velocity is a simple measure of the number of user story points delivered over time. It helps development teams to refine their estimates and plan future sprints. It was never intended to be a way for management to measure team performance.
If you can’t measure it, you can’t manage it.
Yet, managers have a duty and responsibility to measure both individuals and teams. I’ll leave individual performance to the human resources folks. They create elaborate annual performance reviews, and generally do a poor job with them.
As for team performance, what does management want to accomplish? Consider this simple analogy…
Let’s say you meet someone who has never tasted an apple or an orange before, and that person has an opportunity to try one and only one of them, which would you recommend?
You need to compare and contrast an apple and an orange. They are roughly the same size and shape. The colors are different. The skin textures and skin thicknesses are different. The internal structures and tastes are vastly different. Maybe you like apples better. Maybe not. Maybe you hate them both.
I don’t know about you but I’d begin by asking some questions. What kinds of fruits does the person like? Hard or soft? Sweet or sour? Dry or juicy? Eat-on-the-run or sit-and-enjoy? Just-for-one or easy-to-share? If this person has definitive answers, the recommendation should become fairly obvious. If the person is indecisive about likes and dislikes, simply stating your opinion is about all you can do.
It’s about outcomes not metrics.
Similar logic applies to metrics. What is management seeking to fix or improve? Time to market, software quality, estimate accuracy, memory footprint, software execution speed, source code reuse, number of support calls, test coverage, personnel turnover, etc. You need to know what outcome you’re seeking before determining how to measure for it.
Software development is complex. Software tools and hardware devices are constantly changing. There is no single metric that can tell how how well the team is doing from one project to the next. Identify something, just one thing, that you want to improve. Focus on it and devise a metric for it. Set a goal and march toward it.
Once you reach the goal, repeat with another improvement area while you keep measuring what has already been improved. And be flexible. If your last goal was to improve the accuracy of user story estimates and now the team is changing its software toolset, the accuracy will likely degrade at first and possibly improve later.
Metrics are never a static measure.