8 Essential Software Development Metrics for Team Productivity

8 Essential Software Development Metrics for Team Productivity

Data driven software development team leaders know that there is magic and insight in their team data. With the right information at the right time, great managers can identify which teams need help, spot and fix troublesome bottlenecks, and prevent team burnout and attrition. In the world of software engineering metrics, however, there are a lot of KPIs to consider and a lot of competing views on which are the most important. 

For our purposes, we segment software development team metrics into four distinct categories: Speed, Accuracy, Quality, and Joy (for more insight into why we choose this framework, read co-founder and Chief Product Officer, Kevin Steigerwald's piece on the topic here). We're working on compiling The Essential Guide to Software Development Metrics and over the coming weeks, we'll be discussing the key metrics for each category.

For early access to the complete guide, sign up here. 

Today, we start with Speed.


The Essential Software Development Metrics for Team Productivity

Cycle Time

What is the software development metric Cycle Time?

Cycle time measures the amount of time spent working on an issue. Cycle time is the time it takes from an issue to “cycle” from one state to another, usually from some open state to a finished state. Cycle time is a way to understand a team’s speed by breaking total throughput down to median time by either issue type, or status.

When you examine Cycle Time by type, you’re looking at how long a bug or feature or task takes to move from one status to another (eg open to closed). Cycle Time by status, on the other hand, is the time spent in a particular status.

How do you measure Cycle Times?

Your ticket cycle times will be recorded if you are using an issue management system like Pivotal Tracker or JIRA. If you use Notion, we have out-of-the-box metrics that enable you to visualize your Cycle Times by status and by ticket type by extracting that information from JIRA and Pivotal Tracker. Otherwise, you’d need to manually record the time when issues are created and change status.

Why do you measure Cycle Times?

Cycle times help you understand your team’s speed in a different way than velocity or total throughput. By monitoring the time it take for work to progress through your process, you can accurately set expectations or identify bottlenecks affecting your team.

Let’s say you’re focusing on quality, and you want to define an bug turnaround time for your support team. By understanding your bug cycle time, open to resolved, you can communicate the right expectations.

By measuring your typical feature cycle time, open to closed, you can more effectively engage stakeholders and manage their expectations for the delivery of the quarterly roadmap.

A large spike in Cycle Time indicates there are blockers or a breakdown in your process, and it’s time to roll up your sleeves and kickoff of an informed conversation.

Other Relevant Software Development Metrics

You’re probably also tracking:

Counter metrics to consider:


Velocity

What is the software development metric Velocity?

Software development Velocity is a measure of delivered value by the team. Delivered value is typically described as the number of features completed within a period that are ready to ship or ready to test. When teams refer to their velocity, they often mean average velocity -- velocity computed across several intervals to establish a trend.

How do you measure Velocity?

Velocity is measured as the amount of value-added work delivered over an agreed upon time period. Most often, the unit of measure for velocity is story points, but it may also simply be the number of feature tickets if you don’t track story points, and are right-sizing your stories. The key is to be consistent.

With stable teams in place, you’ll establish a baseline of velocity across 3 intervals. If your typical interval -- sprint or delivery cycle -- is weekly, and your team delivered 150 points over the past 3 weeks, then your (average) Velocity is 50 points per week.

Why do you measure Velocity?

Velocity is one of the most popular metrics for tracking the pacing of the team and the objective is to establish a baseline, so you set delivery expectations (when will we finish given the current backlog?) and understand if the team is blocked (falling velocity) or if your process changes are working (stable or increased velocity). It’s important to consider the volatility of your velocity -- how iterations are deviating from the average. If you have high volatility, then something is broken in your process and team, and you need to dig in.

Other Relevant Software Development Metrics

You’re probably also tracking:

Counter metrics to consider:


Throughput

What is the software development metric Throughput?

Software development Throughput is a measure of total work output by the team. Throughput is the number of features, tasks or chores, and bugs completed within a period that are ready to ship or ready to test. When teams refer to their throughput, they’re usually reviewing last period’s throughput, but average throughput can also be useful.

How do you measure Throughput?

Throughput is measured as the amount of work completed over an agreed upon time period. Most often, the unit of measure for throughput is tickets, as it includes features, bugs, and any chores or tasks.

It’s important to go beyond the total number and view this information as a trend of ticket types (features, bugs, tasks) over time to understand the work completed by your team. The ticket type breakdown should correspond to the organization goals.

Why do you measure Throughput?

Throughput is another popular pacing metric like Velocity, but it expresses the total number of units of work (usually tickets) that the team has completed. By measuring throughput, you’re looking for alignment with your goals -- if you’re focused on squashing bugs, you should see a healthy mix of defect tickets being resolved, and if you are focused on features, more featured tickets will be delivered than chores and bugs. If the team is blocked, throughput will drop, and it’s time to dig into root causes.

Throughput can help you with capacity planning by comparing the average throughput against the current workload to help understand possibly overloading of the team.

Other relevant Software Development Metrics

You’re probably also tracking:

Counter metrics to consider:

Want to learn the other 5 essential software development metrics for team productivity ? Click here and find out!

Excellent article! Indeed, a very insightful analysis from the IT perspective. However, we can also determine the efficiency from the accounting perspective- using Cost Accounting, Cashflow, and other metrics. I hope this article will be helpful for a broader understanding of this topic. https://uxdx.com/blog/how-to-measure-efficiency-in-software-development/

回复

Great article and jumping off points Kasey. These will help with consistency and? maintaining through put, do you work with any that look more at the business value of the output and help focus effort not just closing tickets.?

回复
Zack Scriven

I help engineers and executives lead successful digital transformations by providing proven strategies and actionable roadmaps

6 年

You are a woman with many talents! As a former SWE I must say I'm impressed.

回复
Massimo Cibelli Bianco

State of Exterior, LLC

6 年

A most excellent article, I must say.

回复

要查看或添加评论,请登录

Kasey Jones ??的更多文章

社区洞察

其他会员也浏览了