¿QUÉ ES UNA HISTORIA DE USUARIO?
Las historias de usuario son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del sistema. Por lo general, siguen una plantilla simple:
Como <Usuario>
Quiero <algún objetivo>
Para que <motivo>
Las historias de los usuario a menudo se escriben en fichas o notas adhesivas, se almacenan en una caja y se organizan en paredes o mesas para facilitar la planificación y el debate. Como tal, cambian fuertemente el enfoque de escribir sobre las características a discutir. De hecho, estas discusiones son más importantes que cualquier texto que se escriba.
EJEMPLOS DE HISTORIAS DE USUARIO
Uno de los beneficios de las historias de usuario ágiles es que se pueden escribir con distintos niveles de detalle. Podemos escribir una historia de usuario para cubrir grandes cantidades de funcionalidad. Estas grandes historias de usuario generalmente se conocen como épicas. Aquí hay un ejemplo épico de historia de usuario ágil de un producto de copia de seguridad de escritorio:
Como usuario, quiero hacer una copia de seguridad de todo mi disco duro.
¿QUÉ ES UNA HISTORIA DE USUARIO ÉPICA?
Debido a que una épica en general es una historia de usuario demasiado grande para que un equipo ágil la complete en una iteración, se divide en varias historias de usuario más pequeñas antes de que se trabaje en ella. La épica anterior podría dividirse en docenas (o posiblemente cientos), incluidos estos dos:
- Como usuario de poder, quiero especificar archivos o carpetas para realizar copias de seguridad en función del tamaño del archivo, la fecha de creación y la fecha de modificación.
- Como usuario, quiero indicar carpetas que no deben respaldarse para que mi unidad de respaldo no esté llena de cosas que no necesito guardar.
¿QUIEN ESTIMA LAS HISTORIAS DE USUARIO Y QUIEN LAS HACE?
Las historias de usuario la estima el Product Owner (Dueño del Producto), que es quién identifica la necesidad y la puede priorizar y quien debe asegurarse que el producto backlog esté siempre actualizado y priorizado con historias de usuario.
Y, aunque, normalmente, es también el encargado de escribir las historias de usuario, lo cierto es que una vez metidos dentro del proyecto, otros miembros del equipo pueden escribir historias de usuario, siempre manteniendo en mente que será el Product Owner el encargado de incluirlas o no el backlog.
TIPS PARA CONSEGUIR BUENAS HISTORIAS DE USUARIO SCRUM
Ahora que ya sabemos lo que son las historias de usuario, aquí van unos consejos para aseguraros de que sean buenas:
- Las historias de usuario deben ser independientes entre sí, de manera que se puedan llevar a cabo en el orden que más convenga según las prioridades qu establezca el Product Owner en el backlog del producto.
- Su tamaño debe ser pequeño para que puedan asumirse en un sprint y, si es posible, asumir varias dentro del mismo sprint (si son muy grandes, estaríamos hablando de lo que se conoce como un epic, que normalmente está formado por varias historias de usuario de menor tamaño).
- Han de ser estimables, es decir, el equipo de encargado de ellas debe ser capaz de estimar el esfuerzo que supone realizarla.
- Se deben poder negociar entre el Product Owner y el equipo, de manera que se puedan establecer los límites adecuados (aquí entra en juego la Conversación de la que hablábamos más arriba).
- Tienen que tener valor para el usuario, recordad que el PARA es fundamental; la funcionalidad debe ser entendida por todo el equipo.
- Se debe poder testear para confirmar que su implementación es correcta, es decir, cumplir con los criterios de aceptación establecidos.
- Recoge comentarios de los clientes, no te hará falta “inventar” historias de usuarios si las recoge del feedback que ofrecen tus clientes.
En definitiva, las historias de usuario serán las tareas que conformarán el backlog (o pila de producto) en nuestro método ágil, el Product Owner será el encargado de gestionarlas, estimarlas y también de escribirlas, aunque eso no excluye al resto de miembros del equipo. Nos sirven para dividir tareas más grandes en tareas más pequeñas y manejables, que podrán completarse en un sprint o iteración. Y además, son una herramienta que podremos usar para fomentar y mejorar la comunicación de todos los miembros del equipo, puesto que una de sus características esenciales es la conversación y el llegar a acuerdos para confeccionar los criterios de aceptación.
Publicar un comentario