Escribir buenas historias de usuario es un arte que se perfecciona con la práctica. Sin embargo, muchos equipos caen en trampas comunes que reducen la efectividad de esta herramienta. Conocer estos antipatrones es el primer paso para evitarlos.
Uno de los errores más frecuentes es llevar al sprint historias que son demasiado grandes para ser completadas en un solo ciclo. A estas se les conoce como épicas. Por ejemplo, una historia como "Como usuario, quiero gestionar mi perfil" es una épica, ya que implica múltiples acciones (ver, editar, cambiar contraseña, etc.).
Otro error es redactar historias que no aportan un valor visible al usuario, sino que son tareas puramente técnicas. Por ejemplo: "Crear la tabla de usuarios en la base de datos". El usuario final no percibe ningún valor en que exista una tabla.
La clave es aplicar la "S" de INVEST (Small). Las historias deben ser lo suficientemente pequeñas para poder completarse en unos pocos días.
Una historia puede estar bien redactada, pero si sus criterios de aceptación son vagos, deja la puerta abierta a interpretaciones y malentendidos. Esto lleva a que el equipo de desarrollo construya algo diferente a lo que el Product Owner esperaba.
Ejemplo de criterio vago:
Historia: Como usuario, quiero que la página de inicio cargue rápido.
Criterio de Aceptación: La página debe sentirse rápida y responsiva.
¿Qué significa "rápida"? La definición puede variar enormemente entre un desarrollador y un usuario.
Los buenos criterios de aceptación son binarios: o se cumplen o no se cumplen. No debe haber espacio para la opinión. Para ello, deben ser específicos y medibles.
Ejemplo de criterio medible:
Criterio de Aceptación Mejorado: Dado que estoy en una conexión a internet de 10 Mbps, cuando accedo a la página de inicio, esta debe cargar completamente (DOM, imágenes y scripts) en menos de 2.5 segundos.
Este criterio es preciso, medible y se puede automatizar en una prueba de rendimiento, eliminando toda ambigüedad.
Este antipatrón ocurre cuando el Product Owner escribe las historias en solitario, las carga en la herramienta (Jira, Trello, etc.) y las asigna al equipo sin ninguna discusión. El equipo, por su parte, las toma sin hacer preguntas.
El resultado casi siempre es desastroso: el equipo implementa suposiciones que resultan ser incorrectas, se ignoran casos de uso importantes y se construye una funcionalidad que no satisface la necesidad real del usuario. Esto genera frustración, retrabajo y desperdicio.
Una historia de usuario no es un documento de especificaciones detallado; es una invitación a conversar. La solución a este problema es institucionalizar la comunicación a través de las ceremonias ágiles:
Tratar a las historias como el inicio de un diálogo, y no como el final, es fundamental para el éxito de un equipo ágil.