The Agile Manifesto states, ‘Working software is the primary measure of progress.’ However, ‘done’ only tells the half the story. The other half is usually been hidden under the piles of documentation, hours of calls, messages in Slack, Trello boards—the data that keeps magic and insights for software development Team Leaders and Project Managers.

For you to reap better performance benefits, Vice President of Business Development at Svitla, Andrey Okhrimets, shares his experience on how to measure productivity and tells what data is worth to be collected for development teams to ensure the growth. Keep reading to uncover more details.

Why Apply Software Measurements and Metrics?

When properly established, productivity metrics in software development bring a number of gain to everyone working on a project:

Precise planning
Team Lead and Project Manager can better detect, prioritize, and keep a record of occurring issues. It increases overall team productivity level and allows for predicting outcomes more precisely.

Predictable project management
For the team, software development metrics may serve as indicators of what needs immediate fixing, optimizing or regular monitoring. It simplifies the workflow and motivates to search for more suitable solutions.

Strong client relationships
Efficient measurements foster more transparent relationships with clients. In such a way, customers ensure that all the requirements are met within fixed timeframes and budget.

Discovery
Apart from the fact that you can keep work progress under control, the inherent value of metrics is discovery. These little nuggets of gold can transform the direction, focus, and success of your product.

Tip: Scrum-Agile guru Mike Cohn once stated, ‘Don't go overboard and ambitiously commit to collecting 50 different data points for your team. Collect one. Use it. Then pick another.’ In other words, identify first what areas the team needs to improve, and then think on which KPIs could highlight those areas.

Agile Performance Metrics to Count On

1. Actual Stories Completed vs. Committed Stories

What: the metric that shows the team’s ability to understand and predict its capabilities.
How: compare the number of stories committed to in sprint planning with the stories marked as completed in the sprint review.

At Svitla, Build-to-Order Software Application model usually implies teams that use Kanban as the primary method. So the key thing we measure here is the number of tasks accomplished over a set period of time.

And we found this much more effective than any other metrics for software development. For instance, a developer says, ‘I will name that tune for 5 days.’ If they don’t, we try to figure out why they failed and what steps we should take to avoid that in the future. In fact, the most important thing for us is to make a task estimation to a client as veracious as possible.

The benefit to the team
At Svitla, Actual vs. Committed is the key metric, and definitely every software development company should consider it. Gathering and analyzing the data can help you understand what went wrong and who’s in fault: whether it happened because an engineer appointed to the task lacked experience, the tasks were delivered wrong, or the root was in something else. 

For all the Build-to-Order Software Application projects, the use of this metric is crucially important—if developers don’t follow the deadlines they themselves set, everything else has little sense. We cannot say this is some innovative productivity measurement technique, but this is what makes our lives easier.

To be strict about the project estimation is very useful. We strive the one-to-one ratio of the time allotted and spent—no excuses, no scapegoating. And this can only be achieved by adjusting the project management processes—the discrepancy in estimations is often the sign of the poor management in the company as a whole rather than a problem of a particular team member.

Value to the client
Simply put, the main benefit a client gets is confidence. Our clients tend to care about predictability. They want to rely on the team and expect the date a developer specifies is well-grounded, accurate. And there is nothing weird to demand a partner to be good at making and keeping promises, consistently delivering working, tested, remediated software at the end of each sprint. Without stable predictable teams, it’s impossible to have stable predictable products. 

To guarantee customer satisfaction we prefer the number story points delivered to be higher than committed, not vice versa. Thereby, we deal with the performance issue, and clients get even more than they expected.

2. Deviation from the Estimation

What: the gap between the project estimation and actual time spent.
How: compare the time allocated to the task to the time spent.

At Svitla, quality and on-time delivery determine the success of the project. And measuring deviation from the estimation and reducing it helps us constantly deliver the best. Here, one of the key tasks of Project Manager is to keep deviation minimal.

How to achieve this? Give developers a chance to be responsible for their own estimations. The one who estimates and the one who works on the task must be the same person. As simple as that.

Some think, in Agile it’s okay to fail some iteration for the sake of learning. But we consider by default that our teams are already ‘well-trained,’ at least with the typical ones—they are to be estimated over correctly. Say, if the task takes a week, it cannot take 2 weeks—a week and a day in a pinch.  

Svitla Systems has been working as an IT outsourcing development provider for years and learned various clients’ fears and myths firsthand—and ignoring the deadline is definitely on the top the list. So those companies that deliver exactly what and when clients expect them to deliver thrive.

Value to the team
We don’t say companies neglecting this productivity measurement can get problems—they can get problems regardless of whether they measure deviation or not. But if they do, they can get some crucial insights and a chance to make a qualitative leap. Keep deviation minimal, let your developers be accountable for their estimation.

Value to the client
At Svitla, there are a few projects using the perfect Scrum processes, where the clients have allocated Project Owners and are ready to buy all drawbacks of Scrum (for instance, the fact that not all iterations are going to be completed). But it works best only when the client is prepared for Agile processes. A Waterfall company expect staged delivery. So when collaborating with such ones, you need to be very careful with your estimations. Otherwise it’s easy to face a customer dissatisfaction at the end.

3. Client Satisfaction

What: the metric revealing if the team meets client’s expectation.
How: use a feedback system.

If someone wants to deliver a quality product, what is the metric to look for? There are many software development metrics examples to consider: market share, ROI, defect rate. But they don’t say much—in the end what counts is client satisfaction.

Value to the team+client
There are two types of negative feedback you can receive from the stakeholders: direct and indirect. When the client complains, ‘Mike developer is bad, he doesn’t do what I want,’ that is a direct feedback. May happen you get ‘a cry for help’: something goes wrong but no one knows what exactly—this is an indirect one. And its value is in helping Project Manager find gaps and fill them on the go.

Agile Metrics That Are Unlikely to Work

User Stories Completed (per developer)
This is a metric that can be easily manipulated. The problem is that the user stories completed in the backlog are not of equal complexity. And then what? Some developers take simpler ones. When being distributed, that fact divides, not unites. All that fell into the iteration must be done on time—this is the main rule.

To make thing worse, you cannot compare the metrics between teams since all of them estimates differently.

Lines of Code or Hours Spent
This is actually the equivalent of Story Points Completed. The metric is completely useless, as it does not provide any context for interpretation or comparison.

Benchmarking
When it comes to a team performance in software development, the processes vary from team to team, project to project, client to client. So oftentimes, it’s problematic (and incorrect) to compare teams.

Aiming to Progress Rather Than Control
Management is a kind of mastery. Software development teams should be given autonomy to make decisions on their own while sticking to the requirements. Therefore, having a set of comprehensive measure metrics and indicators in software engineering is a must-have. The main point is to analyze the metric data to make further progress. It will not necessarily drive you to the ultimate success, still, you will know when to initiate discussions, develop an action plan, conduct an evaluation, and share feedback.