Validar User Story por parejas: calidad, confianza y conocimiento

En el Sprint Planning todo el equipo tiene en mente el objetivo de la iteración, las tareas más prioritarias, y cómo vamos a mejorar nuestro producto. Durante el Sprint, la validación por parejas de las historias de usuario son fundamentales para que el equipo siga creciendo y mejorando.

¿Qué validamos en una User Story?

• Si se ha implementado la mejor solución de negocio para el usuario.
• Si se ha implementado la mejor solución técnica dada la arquitectura del proyecto y servicios existentes.
• Si el código es claro, se entiende, es fácil de mantener y escalar.
• Si los test implementados para validar automáticamente la historia cubren todos los casos, tanto definidos en las pruebas de aceptación por el Product Owner, como definidos por el equipo para ampliar la garantía de que todo funciona como se espera.
• Si los test implementados para validar se han escrito correctamente. Puede haber test nuevos y pueden haberse tenido que refactorizar test existentes.

¿Por qué es importante validar la User Story por otro compañero?

• Calidad. Todo el tiempo que invertimos en esta validación minimiza el número de bugs en producción, lo que aumenta nuestro tiempo para dedicar a desarrollos evolutivos y de nuevas historias de usuario. En nuestros proyectos, está demostrado que el tiempo dedicado a la validación, es mucho menor que el tiempo que tardamos en corregir el bug, así como solucionar las incidencias que se han producido mientras éste ha estado en el entorno de producción.
• Conocimiento. Puede que una persona haya estado trabajando en otra historia de usuario completamente diferente a la que va a validar, y este ejercicio le permite seguir aprendiendo sobre cómo crece el producto, por si en un futuro se encarga de una mejora sobre esta historia. Además aprende nuevas soluciones técnicas que puede poner en práctica en otros desarrollos.
• Confianza. El equipo mejora sus conocimientos de negocio y técnicos con esta práctica. Cuando haces correcciones a un compañero, y ves que en otra validación futura ha tenido en cuenta esas indicaciones, se gana confianza en que la persona que tienes al lado se toma en serio su trabajo. De esta manera, el tiempo de validación pasa a ser mucho menor y no te ‘da pereza’ hacer esta tarea para tu compañero.

¿Cómo mantenemos esta práctica?

Pues con esfuerzo y constancia. Siempre gusta más desarrollar, poner en práctica nuevos conocimientos, que validar el trabajo de un compañero. Desde que el equipo decide introducir la validación por parejas en el flujo de trabajo, hasta que se mantiente realmente, se convierte en un hábito, se pasan por varias fases:

• Una tarea está pendiente de validar y era crítica para la siguiente entrega. No la validamos por las prisas, subimos a producción y no pasa nada.
• Una tarea está pendiente de validar y era crítica para la siguiente entrega. No la validamos por las prisas, subimos a producción y error, cliente insatisfecho.
• Estimamos la iteración sin tener en cuenta el tiempo de las validaciones.
• Acumulamos validaciones y al final validamos con prisas.

Básicamente, para que esta práctica funcionase, el equipo definió un compromiso:

• Cuando termino mi historia, es más prioritario validar que coger una nueva a desarrollar. Si empezamos a desarrollar antes las historias de más valor, debemos garantizar que estén preparadas para la siguiente entrega.
• Tenemos una fase de validaciones pendientes, ‘Testing’, que está limitada. No debe haber más historias que miembros del equipo.
• Incluir esta fase en nuestro definition of done (DoD). Una historia de usuario no está preparada para subir a producción hasta que un compañero la ha validado.
• El Scrum Master debe dar la voz de alarma en la daily, si alguno de los puntos anteriores no se cumple.
• El equipo recuerda las consecuencias que ha tenido el proyecto al no cumplir esta norma y no quiere volver a pasar por ello.

¿Tu equipo hace validación por parejas?
¿Qué es lo que le aporta y cómo mantienen la práctica?
Y si no lo hacéis, ¿por qué?

Otra forma de abordar la calidad y validación del producto, es designando a una persona en concreto, esto es lo que hace Kaleidos y su Pirata Roberts.