(Este artículo parte de los comentarios realizados en un hilo del foro de Agile Spain)

El equipo es el responsable de proporcionar un producto de calidad, no se puede escudar en etapas posteriores de verificación de calidad o en las pruebas de aceptación del cliente (Product Owner) para no garantizar la calidad del producto que ha construido.

Profundizando en base a la terminología de la ISO9126 de calidad de producto en ingeniería del software:

• La calidad en uso (satisfacción del usuario, efectividad, productividad, seguridad) es un aspecto a verificar por el Product Owner que, además de ser representante de los usuarios finales, también debe asegurar que el producto cumpla con las necesidades del negocio y estratégicas de los stakeholders del proyecto.
• La calidad externa (funcionalidad, usabilidad, eficiencia, mantenibilidad, fiabilidad, portabilidad) en algunos aspectos es más difícil de verificar  por el Product Owner.
• La calidad interna no suele poder ser verificable directamente por el Product Owner.

Como comenta Xavier Quesada en el mencionado hilo, “[allí donde la calidad externa e interna no es observable] el equipo tiene una obligación básica de desarrollar un producto, un software, de calidad, o sea el Product Owner no debe convertirse en el Tester/QA del equipo”.

Si es necesario, el Product Owner se puede servir de diversos mecanismos de apoyo para verificar la calidad externa e interna del producto como, por ejemplo, una auditoría experta. En el caso de desarrollo de software, se trataría de una auditoría del código fuente, patrones arquitectónicos utilizados, trazabilidad entre requisitos (o historias de usuario) respecto a los casos de prueba de aceptación (condiciones de satisfacción) y otros modelos o entregables, etc.

Según se indica en la guía oficial de Scrum, “el Scrum Master entrena y guía al equipo para que sea más productivo y entregue productos de mayor calidad”. Al ser el responsable de la calidad en el proceso, el Scrum  Master guía al Product Owner y al equipo para conseguir que:

• El Product Owner (re)priorice en función del valor aportado al negocio (y el coste de implementación).
• El equipo cumpla con la definición  de hecho que ha sido consensuada con el cliente.
• El Product Owner revise el producto al final de cada iteración, en la reunión de Demostración de los requisitos completados.
• El equipo tome consciencia del producto que está entregando (si cumple con las expectativas del Product Owner, si se está degradando la calidad externa e interna y se está introduciendo “deuda técnica” que dificulte su crecimiento sostenido) y guiarlo para que reaccione si hay problemas (como menciona Xavier Quesada), especialmente en las reuniones de retrospectiva al final de cada iteración. Agilidad es reaccionar ante los impedimentos, problemas, equivocaciones o errores y tomar acciones correctoras, no “mirar a otro lado”, como diría Ángel Medinilla.

• Calidad y agilidad - IV encuentro ágil en Barcelona
• Agilidad es calidad y competitividad