¿Cuál es el tamaño correcto de una User Story o Historia de Usuario?
Muchas veces una de las decisiones a considerar en los equipos que implementan Scrum es el tamaño adecuado de una User Story o historia de Usuario. La historia de usuario al final puede ser tan pequeña que no genera valor para el usuario o demasiado grande que no pueda ser concluida en un sprint o ciclo de desarrollo.
El punto importante a tomar en cuenta es que cuando se depuran las historias de usuarios, el equipo debe involucrar al Product Owner y negociar las funcionalidades con el product Owner si estas se vuelven muy complejas. La negociación lleva al equipo a dividir una historia de usuario en otras de menor tamaño que de igual forma brindan valor al usuario.
Considero que, al desarrollar una historia de Usuario, esta no debe tardar más de tres o cuatro días, de forma que pueda ser parte de un sprint. Incluso es bueno que una historia de Usuario pueda ser controlado dentro de una semana de trabajo, de esta forma al realizar las reuniones diarias se podrá identificar el avance e identificar posibles riesgos de no terminarla y corregirla durante la semana.
Por ejemplo, un website de compras puede requerir que el usuario este identificado e ingrese al sistema antes de realizar una compra. Una manera de definir la historia de Usuario puede ser la siguiente: “como comprador, quiero ingresar al sistema así puedo agregar productos al carrito de compra”.
Para esta historia de usuario, los criterios de aceptación pueden ser:
• Verificar que el usuario tenga la posibilidad de ingresar usuario y clave
• Verificar que el usuario y clave sean validos
• Verificar que el usuario pueda agregar ítems al carrito de compra, sólo si esta logueado
• Verificar que si el usuario sale e ingresa al sistema nuevamente, los ítems del carrito de compra se encuentren guardados y los pueda volver a visualizar, entre otras.
Se observa que, cumplir con la historia de usuario en este caso puede tomar más de tres días en ser completada. Esta se puede dividir en algunas otras historias de usuario. Se podría dividir en tres historias de usuario:
1. Como comprador, debo poder ingresar al sistema y ser identificado en él
2. Como comprador, debo poder agregar ítems al carrito de compra y comprarlos luego
3. Como comprador, debo poder verificar que los ítems del carrito de compra estén disponibles si salgo y vuelvo a ingresar al sistema
Como observa, cada una de estas historia de Usuario le brinda valor al usuario y también se debe considerar que, en este caso, el orden de las historia de Usuario es importante y estamos considerando que el usuario debe ingresar al sistema antes de agregar un ítem al carrito de compra.
Otra opción, que se puede negociar con el Product Owner es que, en lugar de forzar al usuario a ingresar al sistema al agregar los ítems, se puede forzar al usuario a ingresar cuando se de la opción de realizar el pago de los ítems. De esta forma, el orden de las historias de usuario puede cambiar en su forma de ser implementada.
Entonces, la siguiente vez que depure una historia de usuario debe considerar que estas no están escritas en piedra. Se puede y se debe involucrar al Product Owner si hay necesidad de definir nuevamente una historia de usuario.
Este artículo es una traducción del artículo Deciding the size of a User Story.
