Agile software quality metrics and velocity
Many agile metrics are related to velocity since agile is supposed to deliver product faster. That makes sense, you want to measure and manage what it is you want to achieve, speed. Perhaps you think less documentation, no need for a test plan, etc… leads to speed! However, velocity should only be one of several agile software quality metrics. And just thinking and focusing on velocity can have detrimental effects. After all, if you run full speed constantly, the body breaks down. Many forget that one of the keywords in the agile manifesto is ‘sustainable’.
The velocity metric itself has inherent weaknesses in consistency. It only makes sense if the team members are consistent. If your agile team changes such as either in numbers or skills (different team members) or customer-product owner availability variation, then this will impact velocity and cause aberrations in the data. So unless you take note of these contextual elements, you may be chasing your tail trying to keep up with what you ‘think’ you should be able to do, or the velocity of a past sprint, not taking into account other factors.
Velocity, Productivity and Quality
Additionally, if you focus on velocity, a team may sacrifice unit testing, reduce customer meetings, delay bug fixes and refactoring, or many other agile development practices that don’t directly relate to velocity. The objective is not maximum velocity, but rather optimal velocity considering the desired level of quality for the final product. So, not only can you get tired and burn out yourself and your team, if you just pay attention to speed by itself, then you could be shooting yourself in the foot with regards to quality.
So rather than just velocity, here is one other metric to consider:
Finish Rate. Production units (user stories, story points, etc.) planned/completed: This metric shows the deviation in a sprint for what you planned versus what you did. If there is a big deviation, it shows volatility and poor planning, this putting quality at risk. For example, if you plan 100 units, but in the end, you did 130 units, then you have 30/100 (30%) deviation.
Plan accuracy is another that we’ll cover in the next blog. The point is that agile is not supposed to focus on speed. Focus on quality, and you can get speed, but not the other way around.