Agile INVEST – 6 grandes directrices para historias de usuario

Ágil utiliza historias de usuario para expresar los problemas que un producto o sistema debería resolver. La directriz Agile INVEST es un conjunto de recomendaciones compiladas por Bill Wake para ayudar a probar y crear historias de usuario de alta calidad (o más generalmente, elementos del Product Backlog) que apoyen la gestión ágil eficazgestión ágil de proyectos.

Según laAgile INVESTdirectriz, las historias de usuario de alta calidad son fáciles de:

• Entender
• Implementar
• Probar
• Demostrar al cliente
• Ser independiente

Pero desglosemos qué significa realmente el acrónimo INVEST.

Agile INVEST – Independiente

Esto significa que la historia puede existir como un elemento del Product Backlog (PBI) con su propia prioridad, puede estimarse de forma independiente y no depende de ninguna otra historia.

La prioridad asignada a una historia de usuario debería ser el único factor que determine cuándo el equipo la implementa. Si su prioridad es baja, la historia se coloca más abajo en el backlog y se implementa más tarde; si es alta, el equipo la mueve hacia arriba en el backlog para una entrega más rápida. Cuando las historias de usuario son interdependientes, la dependencia —no la prioridad— determina cuándo el equipo las implementa.

Agile INVEST – Negociable

Una buena historia de usuario capta la esencia de la necesidad del cliente. Si hay preguntas, el equipo las discute con el cliente para determinar el valor correcto de la historia. El equipo de desarrollo puede negociar con el Propietario del Producto y los interesados. De esta manera, la colaboración entre el equipo del proyecto (proveedor y cliente) crea un producto o servicio excepcional.

¿Tiene un equipo ágil nada que preguntar porque todo está documentado en la historia de usuario ágil? Entonces un analista de negocios escribió los requisitos.

Habrá algunos elementos no negociables (a menudo no funcionales), tales como:

• Políticas de seguridad relacionadas con las cuentas de usuario
• Requisitos de rendimiento, como el número de usuarios concurrentes que el sistema debe manejar

Eso está bien, siempre que los detalles de la funcionalidad en sí permanezcan abiertos y fomenten la conversación.

Agile INVEST – Valioso

Refiriéndose a los principios ágiles, ‘valioso’ significa que podemos demostrar la característica o funcionalidad solicitada al cliente durante la reunión de revisión del sprint.

Al dividir historias de usuario, los equipos deben dividirlas verticalmente (también representando la ‘V’) en lugar de horizontalmente. Esto entrega funcionalidad completa al final del sprint y aumenta el incremento potencialmente entregable del producto.

Los equipos pueden encontrar más interesante implementar PBIs técnicos, pero no siempre entregan valor directo al cliente, lo cual contradice uno de losprincipios ágiles: satisfacer al cliente mediante la entrega temprana y continua de software valioso.

Agile INVEST – Estimable

Una buena historia de usuario debe ser estimable. En ágil, la estimación es relativa, comparada con las demás historias de usuario en el backlog. Los métodos populares incluyen la secuencia de Fibonacci, Tamaño de camiseta (S, M, L, etc.), y más.

La discusión sobre la estimación ayuda a todo el equipo a alcanzar un consenso sobre las condiciones necesarias para completar la historia. A veces una historia no es estimable, lo cual es normal si la historia es demasiado grande o contiene múltiples funciones dentro del mismo elemento. En tales casos, divida la historia en múltiples historias más pequeñas. En otras situaciones, hay demasiadas incertidumbres que requieren investigación.

Agile INVEST – Pequeña

Las historias deben tomar desde unas pocas horas hasta un máximo de una duración completa de Sprint. De lo contrario, surgen diferentes problemas, como la velocidad (cómo el equipo se responsabiliza por los puntos de entrega), la dificultad para una estimación precisa, y más.

Agile INVEST – Verificable

En este contexto, ‘verificable’ se refiere a los criterios de aceptación definidos durante el análisis.

No podemos considerar una historia de usuario como ‘terminada’ a menos que cumpla con los criterios de aceptación. La única forma en que sabemos que se cumple es mediante pruebas y verificación.

Los criterios de aceptación no son casos de prueba. Responden a la pregunta: ‘¿Cómo sé cuándo he terminado esta historia de usuario?’

Los casos de prueba detallan los pasos necesarios para probar la funcionalidad.

El cliente puede indicarte cómo es el entorno de pruebas y las condiciones de prueba bajo las cuales el equipo considera que una historia de usuario está TERMINADA.