Metrics mean accountability. They hold the team accountable for the work they’re putting in. This doesn’t mean the metrics are just for managers to hold over everyone’s heads. Their main purpose is to improve the results of the team by pointing out areas of excellence as well as shortcomings. Without metrics software teams might start missing deadlines and produce low-quality work. How long do you think such a situation is sustainable?
But what about being “agile?” Don’t metrics fly in the face of an agile team because they represent corporate structure and bureaucracy? While you don’t want to overanalyze the team, you must have metrics because it shows your clients that you care about the details.
Metrics help the team see the big picture, with insights into:
- Overall performance
- Assessments of the quality of the software delivered vs. requirements
- The speed of delivery of the product and time spent on each stage
- Uncovering areas for improvement that might require more resources or staff
Pick Metrics that Matter
The goal for your development team should be a gradual improvement. Your processes and environments should get better because they’re tied to metrics. You have to measure and share the metrics that make the most sense for your goals. And be flexible. The makeup of your team might change, just as business conditions and your market opportunities can shift. Remember that the metrics are simply tools to help you improve because they uncover insights.
Communicate Results
Metrics shouldn’t remain a mystery. If you’re collecting information and locking it away then it loses value. Transparent communication of issues with the metrics means you see the team members as partners. Get any problems out in the open and set expectations at the beginning of the project. Sharing the metrics across the entire team can prevent misunderstandings and tension, two elements that can kill the productivity of even the best teams. You should also celebrate improvements with the entire group. Let them know their work is appreciated, especially when they’ve positively adjusted their processes in response to metrics.
Top Metrics for Measurable Improvements
These first four metrics fall under the “agile” umbrella and are vital for understanding how the team responds to changes.
- Cycle time: The time it takes to make a software system change and move it into production. Within a continuous delivery model it’s possible to get cycle times down to increments of minutes. This is a useful metric for spotting inefficiencies. Perhaps the team is performing too many manual verifications. Or the work isn’t separated into more manageable pieces.
- Lead time: How quickly can the team move from an idea to delivery? Higher lead times mean there’s likely excessive wait time and poor decision making within the process.
- Velocity: The number of units of software that are finished within a single iteration of the system. Measuring velocity can be tricky because projects (and the attached sprints) vary greatly and it’s not useful to compare velocity between two or more teams.
- BurnDown Charts: These are representations of the work that’s needed to complete a certain project compared to the agreed-upon time that’s left. These are often used within Scrum and agile developments and presented graphically so the team can see at a glance how they’re doing. Ideally, the work will finish on a fairly straight progression through a sprint. If you’re seeing a spike towards the end of the time axis, then you know the team’s cramming in work at the last minute. That’s a recipe for errors.
- With these metrics, be sure you talk to the team about any “outliers.” Don’t just assume they’re off track due to the numbers, as there might be some extenuating circumstances or internal reasons for the metrics. Metrics are supposed to provide context into the broader conversation of improvement.Additional metrics that should be on every Software Development Metrics team’s radar include:
- Production bug queue: This is simply the open number of production bugs. They should be prioritized and each team should strive towards that magical “zero.” Watch this metric carefully because high numbers of bugs breed complacency. The team might start working on new features while ignoring old bugs. The end result? Spotty quality and dissatisfied clients.
- Security metrics such as endpoint incidents. This metric looks at the number of endpoints such as devices and workstations that have been infected during a certain timeframe. Spikes in this metric point to faulty security protocols and warrant the team’s careful review. Another security metric is MTTR (mean time to repair) which is simply the time between finding a security breach and deploying a fix. Essentially, can the team fix bugs, and can they do it faster over time. Security is often overlooked, but the damage done to the client and your brand in the event of a breach is substantial.
- Open pull requests: With this metric you’re looking at the number of pull requests that have not been closed. These requests are how a developer requests the team look at changes made within a repository. This gives the team and managers a chance to review and adjust the changes and perform other actions. This metric is valuable because it affects throughput and can boost delivery time. It also uncovers shortcomings in your code review processes, allowing you to pull in more resources if needed.
Throughout this metrics-review process, remember that the customer experience and fulfilling their needs is the paramount goal. If your metrics look great for the delivery of things the client doesn’t really want, then you can’t really claim success. Make sure the metric improvements and adjustments pay off in terms of client satisfaction, which is the measurement that really matters.
Looking for help with your vital Software Development Metrics? Sphere provides expertise into the entire software development process, including how to leverage metrics for optimal efficiency and performance.
