Las historias de usuario constituyen el corazón del desarrollo ágil. Son la entrada principal para el equipo scrum. Ellos toman las historias de usuario y crean incrementos de producto basados en completar esas historias. Desgraciadamente, hacer bien las historias de usuario no es tan fácil.
Puedes conocer más información sobre las historias de usuario aquí:
Los Product Owners necesitan aprender a crear historias de usuario que satisfagan las necesidades del equipo. Para crear buenas historias de usuario, hay que empezar por recordar que hay que INVERTIR en buenas historias de usuario. INVEST es un acrónimo que engloba los siguientes conceptos que conforman una buena historia de usuario:
Independiente: Un elemento del Product Backlog (PBI) debe ser autocontenido.
Negociable: Debe dejar espacio para la discusión.
Valioso: Debe aportar valor a los interesados.
Estimable: Siempre se debe poder estimar el tamaño de un PBI.
Pequeño: Así se debe poder planificar, asignar tareas y priorizar.
Testable: El desarrollo debe poder ser probado.
Las historias deben ser lo más independientes posible y debes poder trabajar en ellas en cualquier orden. Esto permite una verdadera priorización de todas y cada una de las historias. Cuando las dependencias entran en juego, puede que no sea posible implementar una historia valiosa sin implementar otras historias mucho menos valiosas.
Negociable
Una buena historia es negociable y no un contrato. Una buena historia es una invitación a una conversación. Una buena historia capta la esencia de lo que se desea. El resultado real tiene que ser el resultado de una negociación colaborativa entre el Product Owner y el equipo de desarrollo. El objetivo es satisfacer las necesidades del cliente.
Valor
Las historias de usuario deben ser priorizadas en el backlog según el valor del negocio. Llegar con elementos del backlog del producto que son realmente divertidos de codificar pero que no aportan valor a los interesados, viola uno de los Principios Ágiles, que es entregar continuamente software valioso
Estimable
Los desarrolladores deben ser capaces de estimar una historia. Debe estar escrita de tal manera que los desarrolladores puedan entenderla y tener una idea de cómo implementarla. Los factores clave para la estimación son el conocimiento del dominio y el conocimiento técnico.
Pequeñas
Las buenas historias tienden a ser pequeñas, pero ¿cuán pequeñas deben ser? La respuesta depende del equipo y de la metodología que se utilice. Una gran cantidad de Product Owners sugiere iteraciones de dos semanas, que permiten historias de usuario de tres o cuatro días promedio de trabajo. Esto incluye todo el trabajo para llevar la historia a un estado «hecho».
Testable
Las historias deben ser testable con el fin de ayudar a determinar la integridad. Una historia debe tener un criterio de aceptación. Los criterios de aceptación deben ser objetivos. Evite usar criterios como, fácil de usar, rápido o libre de errores. Try to write criteria that can be measured and tested.
Via: