This article was originally published by Index Code

 

Research shows that remote teams work more productively than those based in an office. The question is: how much more productive are remote software engineers? 

 

Managers who are interested in learning how remote work is impacting their team’s performance might set some key performance indicators. Some KPIs are better than others: data points such as lines of code, hours worked, and bugs fixed offer a false impression of productivity. As one expert writes, “these half-baked metrics are used to measure the wrong thing. They’re easy to game. And they don’t provide any real or actionable insight that individuals or teams can use to improve their performance.” 

 

It’s critical to measure the right metrics to keep your software development projects on track without destroying team morale. Empower your developers to work productively by giving them the right tools. To keep everyone on track, set your team up for success with these key performance metrics.

 

Cycle time

“Cycle time” is a measure of the time it takes for a bug, feature, or task to move from one status to another. It can tell you more about a team’s speed and productivity. This KPI should be classified into issue types – i.e., bug cycle vs new feature development. Your project management platform, like JIRA, will tell you what your cycle time is, measured by when a ticket comes in through each phase until the ticket is closed. Cycle time can tell you where there are bottlenecks, blockers, or breakdowns in your process and help set expectations for other teams in your organization for getting their issue addressed by your development team.

Sprint burndown

Sprint burndown is a metric integral to agile scrum, and tells you “the rate at which work is completed and how much work remains to be done.” This graph plots outstanding work to be done on the y-axis, and time along the x-axis. By tracking this metric, you can discern whether or not your team is running on schedule, as well as if a project has been scoped correctly. It can also help you plan your sprints more effectively, delegating work in granular pieces to keep your team from getting burned out. 

Velocity

Velocity tells you how much “delivered value” your software developers accomplished. “Delivered value is typically described as the number of features completed within a period that are ready to ship or ready to test,” adds one developer blog. 

 

Velocity is measured in story points or feature tickets, and can help you: 

• Set delivery expectations
• Forecast realistic sprints 
• See if your team is blocked (falling velocity)
• See if by changing a process you gain better results (stable or increased velocity)
• Spot any challenges that you didn’t account for in sprint planning

 

If your velocity metric varies wildly from week to week, then there’s something standing in the way of your software developers’ performance success. It can be a red flag if you see your velocity metric swing away from the average; something is broken in your process, so how can you fix it? 

Open requests

Open requests, or open pull requests, tell you how many requests have not been addressed. If it’s a pull request, it tells you whether or not your team is working together efficiently. Pull requests are queries from one developer to the rest of the team to review changes or provide input. If no one from the team can provide feedback, then the request remains open, stalling other requests or parts of a sprint. “Tracking Open Pull Requests over time will allow you to spot bottlenecks in your feature delivery process and allocate either more time or more resources for code review,” reports one developer blog.

Throughput

Last but not least, throughput is a measure of total work output – including the number of features, tasks, bugs, or chores completed that are ready to test and ship. Throughput is measured over a discrete period (like a week or a month) and tracked over time so you can see that your team is working consistently. “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.” Refer to your tickets to get an accurate measure of throughput and help your software developers work productively.