Software development metrics you should be tracking

0


[ad_1]

Billy Beane, general manager of the Oakland A’s in 2002, lost his top three baseball players to free agencies and had little money to spend on other superstars. Instead, he focused on using a specific set of metrics – hitting percentage and base percentage – to build a squad of undervalued and unannounced players, much to the bewilderment of the world of the game. baseball.

The result: Beane led the A’s to the fifth-longest winning streak in baseball history and three American Western League titles in five years.

For software development teams, metrics can also be used not only to understand how productive and efficient a team is at various tasks, but also to predict future changes in that efficiency and overcome obstacles along the way. Rather than early stage development, DevOps metrics typically focus on deployment, operations, and support. To this end, the metrics themselves are frequently divided into three specific categories: people (such as response time); process (time frame); and technology (uptime).

While some of the more common metrics are known to many DevOps teams, other lesser-known metrics can also have a major influence. Just as Billy Beane focused on specific metrics to unlock new understandings of baseball productivity, we sought to find unique data points that do the same for software engineers. We sat down with three engineering managers to discuss the software development metrics they use to measure the productivity of their engineering teams.

Best software development metrics

  • Deployment frequency
  • Sprint speed
  • Uptime
  • Average recovery time
  • Lead time
  • Changing the failure rate
  • Points completed per person per day
  • Predictability rate
  • Team happiness

Cinqtran

Teen Mathew

ENGINEERING DIRECTOR

What metrics do you use to measure the productivity of your engineering team, and why?

The teams I work with at Fivetran track sprint speed, rate of inbound incidents, and code debt. Sprint speed tracking allows teams, especially engineering, products, and prospects, to examine data from previous iterations and commit to what’s doable.

Regarding the rate of inbound incidents, my teams prioritize customer issues based on a prioritization matrix. Tracking the number of inbound issues recorded by customer support, sales, and internal teams helps us stay agile and re-prioritize when necessary.

We track code debt to make sure the code remains maintainable. It also helps to keep remediation costs to a minimum.

By refining and standardizing story pointing, the team understands and discusses the complexity of a task without basing it on an individual’s knowledge.

What are the examples of information that you learned from these metrics and what actions resulted from them?

Initially, I noticed a lot of variation in the sprint speed. For example, on a team of five there were sprints with 100 story points and some with 45 story points. This variation has forced us to take action in several ways.

First, we realized that the story scoring identified was not consistent, so we did some story scoring training with our teams using examples from our future tasks.

We also had to normalize the sprint speed to balance the load. We realized that the difference in the number of story points completed had to be plus or minus five points to achieve a comfortable engagement rate for our teams.

How has tracking these metrics (and acting on the data) impacted your team’s productivity?

By refining and standardizing story pointing, the team understands and discusses the complexity of a task without basing it on an individual’s knowledge. This has helped improve the speed of the team as we now rely on each other for task completion.

Keeping track of inbound incident rates helps us improve and deliver speed. We plan future quarters based on the type of incoming incidents and engineering priorities which include feature proposals based on the types of incidents. This has increased the speed of delivery of our features over time while reducing the rate of inbound incidents.

megaphone

Ben Levine

VP OF SOFTWARE ENGINEERING

Ben Levine

What metrics do you use to measure the productivity of your engineering team, and why?

At Bullhorn, we operate a variety of metrics that are meant not only for consumption and leadership review, but also for the whole team to use and assimilate. We believe the team is in the best position to see changes in the data and act quickly, so everything we look at at the executive level is open and visible. The metrics we leverage to access productivity include speed (measure of story points completed per sprint), points completed per person, points completed per day (this includes developers and testers), fixes by release (the fix is ​​any ticket delivered outside of a release candidate), minor releases by cycle, and release size.

In addition, our metrics include the percentage of planned versus unplanned tickets (planned tickets are those the team committed to during sprint planning), the percentage of tickets prepared at the start of the sprint, the unit test coverage by depot and automation test coverage.

We leverage this set of data points because it allows teams and their leaders to have a holistic view of the health of the team and each project. It also gives us the ability to deliver a consistent product to our customers while reducing the benefits of trying to mess with the system by seeking to drive measurement in an unnatural way. And finally, it allows each team to see the first signs of trouble and pivot quickly.

Metrics help teams constantly improve. “

What is an example of information you learned from these metrics, and what actions resulted from it?

By leveraging the review of patches and cycle deployments, we found that the patch delivery level and associated churn rate was magnified by the smaller but fast nature of the patch vehicles being delivered. Since each vehicle created a level of overhead and need to deploy, by reducing the number of vehicles to set the days of the week and packing a few items into each vehicle, we were able to reduce the churn rate for teams. and plan for more consistency in the delivery of the sprint.

Additionally, by looking at both speed and points per person per day, we can see how changes in team capacity and alignment are impacting the team’s ability to deliver. This helps us understand the impact of resource changes between teams and the roadmap, and allows us to be much more deliberate and strategic in team changes to minimize the disruption that changes can cause. It also helps us to ensure that we are always supporting the changing needs of customers and businesses.

How does tracking these metrics and data action impact your team’s productivity?

Tracking these metrics and, in particular, integrating them into the conversation teams have in retrospective forums and the like, has had a positive impact on team productivity.

Metrics help teams constantly improve. It allows direct and timely feedback on the impact of changes made by the team. It also allows them to understand what works and what does not. This information, combined with a broader review, allows our teams to share ideas on exactly how to improve productivity.

During the pandemic, we have seen our teams continue to improve their number of deliveries in all areas despite the chaotic nature of the changes in the work environment and the state of the world occurring around them.

Revision

Jason Vertrées

SVP OF TECHNOLOGY

Jason Vertrées

Jason Vertrees is senior vice president of technology at Overhaul, a supply chain integrity solutions company. While his engineering team uses a variety of metrics to measure productivity, he focused on two useful metrics in particular that unlocked better models of speed and prediction on the job.

What metrics do you use to measure the productivity of your engineering team, and why?

There are standard metrics that many businesses focus on, including us, such as uptime, average recovery time, turnaround time, change failure rate, and frequency of deployment. Most know them, so I’ll talk about something else.

Two that I have found useful aside from the above are “team happiness” and “predictability rate”.

What actions resulted from these insights?

“Team happiness”, while subjective, can be cast on a Likert-type scale giving you the ability to quantify it. In addition, happiness is a leading indicator (not a lagging one): if your happiness decreases, your speed ahead will decrease accordingly.

Predictability helps us measure the percentage of large projects delivered on time. This helps us refine our estimates, which are essential for the planning of external teams.

Happiness is a leading indicator (not a lagging one): if your happiness decreases, your speed ahead will decrease accordingly.

How has tracking these metrics (and acting on the data) impacted your team’s productivity?

The intentional focus on happiness has helped us uncover the sources of lost productivity.

I used it on a project and at one point we noticed a drop in team happiness. Once the decreased scores were spotted, this sparked a series of questions in the retrospective where two non-technical reasons surfaced: lack of preparation / clear product requirements and developers’ feeling that management was not actively listening. After knowing the cause, we were able to solve the problems, restore the excellent performance of this team, happiness and confidence in management.

[ad_2]

Share.

Comments are closed.