Agile metrics offer insight into team productivity throughout the software development cycle. They help evaluate a product’s quality and track the performance of a team. While good metrics are important, bad ones can make the life of a team miserable. Learn more info about this below:

Importance of Metrics

What results do you want to achieve? How do you measure success? There are unlimited possibilities and picking good metrics to track can be challenging. Good metrics deliver value to your team and offer information that lets you take action that produces value. But bad metrics can measure something that does not help create value. Also, they can seriously affect team motivation. 

Avoiding Bad Metrics

In software development, you can avoid using bad metrics by measuring only the right things. For example, metrics linked with yearly performance reviews and financial bonuses are common.  Using these metrics can result in targets being decided a year ahead and then frozen. 

A frozen bonus plan decreases team agility. A development team may focus on working on things the plan lists instead of things with better value. Team performance bonuses should be tied to a product’s business results instead. 

Moreover, bad metrics encourage teams to do something to make them look good. As a result, teams put aside things that offer more value. In fact, they may consider what creates value and only pay attention to what’s measured. So, to make sure that the use of metrics makes sense, it is important to stop the gaming.

Examples of Bad Metrics

The following are examples of metrics that must be avoided:

• Specification changes. Measuring the number of changes made to a specification does not give valuable information. Good metrics measure something that has value or activities that result in value. It should measure how well your team is doing.
• Code changes. Knowing the number of changes made to codes allows your team to get feedback on a demo, prototype, or release, so they can change the implementation. However, when such changes are made early, the implementation may need to be continually changed during construction. 
• Commit count. If you measure the number of commits made by a developer, what does this measure? This only motivates developers to check in changes in small batches instead of big ones. 
• Velocity. This metric can help teams decide on a great level of work commitment. It is used for deciding the amount that should be loaded to a sprint. But velocity can become a flawed metric when teams use it for comparing with each other.  Regardless of a team’s velocity, they must not make a comparison.