Three Metrics Your Agile Team Should Stop Using

This is a guest post by Nishi Grover Garg.

Metrics are supposed to help and support an agile team by providing useful information about the health and progress of their project. But not all metrics are always beneficial. Going overboard with them can sometimes cause more harm than good.

Here are three metrics that can impede your agile team instead of motivating you.

Defect Counts

The first and most obvious metric that is not useful to agile teams is counting the number of defects. Whether you’re totaling the number of defects per sprint or the number of defects logged by certain people, trying to figure out product quality or progress using defect counts is never a good idea.

It pits people against each other, and it incentivizes testers to report a greater number of bugs rather than focus on finding real, quality bugs. Defect rejection rates may increase because developers do not want higher numbers of defects against their names. This metric adversely affects overall teamwork, and the agile mindset suffers.

Modern Test Case Management Software for QA and Development Teams

Hours

An agile team is supposed to be a value-driven, self-managed and disciplined entity, focused on providing working software. They are aware of their short timeboxes and their goals for each iteration. They also estimate their own tasks and user stories and provide each other with daily updates. Beyond this, there seems to be no need of measuring their time.

Even though you may need to monitor time spent on a user story by adding actual vs. estimated hours, there is a lot of time spent on meetings, discussions, collaborations, and reviews that may not be accounted for. Old-school managers may need to get over their urge to check on each person’s daily schedule, time spent on desk, or the need to log a certain number of hours in the office.

You should also do away with having to log each activity in a tracker, because most collaboration and communication can (and will) happen in an informal manner between peers. Agile teams work best when teams are self-driven, motivated and then trusted to deliver.

Lines of Code or Defect Fixes per Developer

When you measure developers’ performance based on the number of lines of code they wrote or the number of defects they fixed individually, it is bound to influence how they work. For example, if a better design concept for a user story implementation uses fewer lines of code than a simpler but cruder way, which one would you want your developer to pick?

Similarly, if you look at the number of defects fixed by each developer, it assumes that each defect takes a similar amount of effort. Developers will be tempted to pick simpler issues that take less time to fix, while the important defects that really need to be addressed will linger because they take more time.

You may still need to look at lines of code or the defect fix rate as generic metrics for the project’s progress or to resolve the team’s bottlenecks. But you should not use them to measure individual performance, because it will impact people’s way of working and thinking. They will try to adjust the numbers in their favor, and the product’s overall quality may go by the wayside or become impossible to accurately assess.

Metrics can be useful tools for managing any project, but we must focus on choosing metrics that enhance the quality and pace of our work, not impede it.

All-in-one Test Automation Cross-Technology | Cross-Device | Cross-Platform


Nishi is a corporate trainer, an agile enthusiast and a tester at heart! With 11+ years of industry experience, she currently works with Sahi Pro as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.

In This Article:

Try a 30-day trial of TestRail today!

Share this article

Other Blogs

Software Testing Life Cycle (STLC): Best Practices for Optimizing Testing
Agile, Automation, Continuous Delivery, Integrations, Software Quality

Software Testing Life Cycle (STLC): Best Practices for Optimizing Testing

Delivering high-quality software becomes challenging when testing lacks structure and detail. Without a clear process, bugs may go undetected until later stages of development—or even after release—leading to higher costs and dissatisfied users. To avoid these...
Defect Tracking: Best Practices and Essential Tools
Agile, Continuous Delivery, Performance, Security, Software Quality

Defect Tracking: Best Practices and Essential Tools

In 2022, poor software quality cost the U.S. economy at least $2.41 trillion—a staggering number that highlights the impact of defects slipping through the cracks. Many of these issues stem from poor decisions, inadequate management, and overlooked risks that ...
integration testing
Agile, Automation, Integrations, Software Quality

Integration Testing: How to Get it Right

When different software modules come together, things don’t always go smoothly. Miscommunication, data mismatches, and other issues can creep in, making the application unreliable and harder to debug. That’s where integration testing steps in. It ensures that ...