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.
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.
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.
