A negative metric is a performance indicator that tells us if something is going badly, but it doesn't show us when that same something is necessarily going well.     

For example, velocity. If our velocity is low or fluctuating between iterations, this could be a sign that something isn't going well. However, if velocity is normal, there is no guarantee that the team is delivering useful software. We know that they are working, but that is all we know. Measuring the delivery of valuable software requires a combination of other metrics, including feedback from our customer.

Therefore, velocity is only useful if it's being used to determine what the team is capable of during each Sprint. It will also aid in scheduling releases, but it is no guarantee that the product under development is on track to being fit for purpose.

Something we should also be aware of with metrics such as velocity is that the very act of focusing on them has the potential to cause a decrease in the performance we desire. A common request to teams is to increase their velocity because we want to get more done. In this situation, the team will raise their velocity, but it won't necessarily increase output.

Instead, a team may conclude that they were too optimistic in their estimates and decide to recalibrate their Story Points. So now a story that would have been five Story Points is eight Story Points instead. This bump in Story Points means they will get more Story Points done in the same amount of time, increasing their velocity.

In my experience, this isn't something done deliberately by a team. Instead, it's done because attention was drawn to a particular measurement, causing the problem to be analyzed and corrected. Unfortunately for us, negative metrics aren't the ones we should be poking around with.

Other examples of negative metrics in software product development are:

• Lines of code written: Shows us that our developers are writing code, but doesn't testify to the usefulness or quality of that software in any way. Focus on this metric, and you will certainly get an increase in lines of code written if nothing else.
• Test code coverage: The percentage of code covered by automated tests. Shows that tests have been written to run the code, but there’s no guarantee of the effectiveness of those tests in terms of preventing bugs.

Examples of metrics that we could focus on:

• Value delivered: Is the customer getting what they want/need?
• The flow of value: How much and how often is value delivered?
• Code quality: Multiple measurements which focus on two critical characteristics of our software:
  1. Is it fit for purpose?
  2. How easy is it to maintain?

One fit-for-purpose quality that our customer should care about is the number of bugs released into the wild. This includes bugs that result from a misunderstanding of requirements. The further down the value stream we find bugs, the more expensive they will be to fix. Agile methods advocate testing from the get-go.

• The happiness of our team(s): Happy teams are working in a way that is sustainable, with no extended hours or weekend work. Standards and quality will be high. Our team will have a good sense of satisfaction.

In short, negative metrics have their place; however, used unwisely they can have unintentional side-effects and degrade the performance you're looking to enhance.

In the following sections, we'll look at various measurements and how to use them.