Qualocity

In Agile IT projects, the quality of the product is expected to be high and non-negotiable. Velocity and scope are the factors that change with every sprint, but not the quality. An Agile project team should always deliver "the right" quality. But is that the case in the projects you have worked on? If not, is there a way to shift the focus onto quality?

In Scrum we always talk about velocity. We measure the story points that are burned down in the sprint. And it is expected that the delivered stories are of “top” quality. The quality standard of the team is defined in the Definition of Done (DoD). And every story that meets this DoD adds up to the velocity. In projects I have worked on there is always some pressure to deliver and prevailing circumstances that make the developers take shortcuts which introduce some technical debt by not delivering the quality they (normally) would agree to deliver.

A way to shift the focus onto quality is to introduce a quality factor. How does a team determine the quality factor? That is up to the team of course, just as they also determine their own story points. But the main difference is that the quality factor is determined after the story is delivered. Because only then is it clear what the actual quality of the delivered IT products is. A suggestion is, when a story is finished according to the agreed quality standards of the team (DoD) the quality factor Is 1. When the story is finished with “premium quality” the factor is 1,5. The engineer created “cleaner code” or complied to the (optional) coding standards. Or the code is refactored and easier to maintain. But when a shortcut is taken and some technical debt is introduced the factor is 0,5. Because this will slow down the team in the future.

If the quality factor of a story is combined with the story points (velocity), then you get a new kind of "speed". The Quality combined with the Velocity. I would like to suggest to call that the Qualocity of the team. A beautiful marriage between Quality and Velocity. Because we want to make quality part of the team discussion. We already measure the velocity in the sprint but we should also measure the quality of the product at the end of sprint. What is nice about this, is that we do not need a separate metric, just combine the quality factor and the velocity to measure the Qualocity.

By measuring the Qualocity the focus can shift from pure velocity to the combination of delivering value with speed AND the right quality. Asking questions about this factor will help the team to find ways to deliver better quality. This will contribute to the quality discussions in your team. In the end it is all about delivering value for the customer and all customers value quality.