Managing software teams can be challenging and with more people working in a distributed capacity, managers have additional challenges. With these new and existing challenges, the ability to measure your team’s progress has grown in importance.
The COVID pandemic changed how software teams work. Collaborating in the office used to be the norm. Having the water cooler conversations and huddling in a conference room were often instrumental in solving challenges. Ad hoc interactions allowed for team members to mesh, identify other’s non-verbal cues, and promote collaboration. Distributed teams lose some of these abilities, especially the ability to identify teammates non-verbal cues. When critical dates and milestones are at risk, the performance of your team becomes ever more important.
Statistics can, and should, help drive software engineering teams to excellence. There are key metrics that most teams should be paying attention to regularly—but not at the expense of innovation or creativity.
Start by Asking the Right Questions
Most folks don’t take a vacation without first knowing the destination. Without the end in mind, planning a vacation becomes increasingly difficult.
Metrics won’t matter until you first ask the right questions. Defining the goals and challenges needing to be solved is the first critical step. You can then identify the correct metrics to measure and how they tie into the bigger picture. The team must understand why the metrics are important so that they can make the right decisions.
Metrics
Below are several different metrics to evaluate a team and/or its members. It is not necessary to use every metric, pick the right combination for you and your team. Focusing on the wrong metrics can inadvertently lead to making incorrect decisions.
Team
Measures specifically how your team is performing over a period.
- Velocity – Represents the amount of work completed in each iteration or sprint and provides insight into the team’s productivity and efficiency over time
- Burndown / Burnup – Remaining work versus time, helping teams identify potential bottlenecks and adjust their efforts accordingly
- Cycle Time – The time it takes for a task to move from start to finish. Provides insights into process efficiency and helps identify areas for improvement.
- Work in Progress (WIP) – The amount of work that has been started and not yet completed.
- Forecast vs Actual – Represents the accuracy of estimates and execution from a team.
Code
Measures the overall health of your code base.
- Open Defects – The number of open defects that belong to a given product. There are several other quality related metrics that go along with measuring Open Defects – Priority, Severity, Time to Close.
- Static Analysis – While not a metric, using a static code analysis tool that measures code quality can provide great insight. Most tools will allow for configuration for your team’s practices and standards.
- Time in (code) review – Represents how efficient and thorough the team’s code review practices are.
- Code Coverage – Represents the proportion of source code that is executed during automated tests. It indicates how thoroughly a test suite exercises the codebase and helps assess the effectiveness of testing efforts. It’s a useful tool for identifying areas of the codebase that are not adequately tested, enabling developers to improve test coverage and identify potential bugs or regressions.
Customer
Measures how customers are responding to your product or service.
- Customer Satisfaction – Assess satisfaction with the team’s deliverables. Ultimately, customer satisfaction is a key measure of the team’s performance and value delivery.
- User Adoption Rate – Represents how many users are signing up and using a product or system.
- Conversion Rate (trial -> paid) – Measures the number of users that generate revenue for the company.
Implement, Iterate, Communicate
After you have identified your key metrics, it’s time to implement and monitor. Just as a software team performs a sprint retrospective to improve, it’s important to periodically evaluate your metrics to ensure that you and your team are making the correct decisions. Without the right information, you may be solving the wrong problems or implementing poor solutions.
Lastly, regularly communicate the metrics with the team. Let the team know how they are performing. Without this feedback, the team will not be able to adjust and improve. Empowering the team to review the information and make changes in the software and their own behavior.
A Word of Caution
While metrics are useful, they must be used thoughtfully.
Micromanaging metrics can demoralize a team, and stifle creativity and innovation. Constantly reminding a team that they are underperforming in certain areas will not create improvement. Metrics should be a part of the conversation and plan on how to improve.
A key tip is to “Catch them doing good things” to highlight success, while suggesting areas for improvement.