Muchas veces según vamos descubriendo las necesidades del usuario nos ponemos a plasmarlas sin más en Historias de Usuario. Al hacerlo así, corremos el riesgo de que nuestras historias no estén bien redactadas y puedan bloquearse fácilmente o entorpecer el proceso de desarrollo por no tener el tamaño adecuado o bien definidos sus tests.
Es muy importante, a la hora de redactar las historias, seguir unas mínimas pautas para evitar todo esto.
Mike Cohn, en el libro “User Stories Applied” explica en profundidad el uso de Historias de Usuario. Enseña técnicas y da pistas sobre cómo recabar, escribir y estimar una buena Historia de usuario. Mike Cohn es uno de mis autores favoritos de agilidad, entre otras cosas por la claridad a la hora de explicar sus ideas, por lo que aconsejo a todos los Product Owner leer este libro con calma a fin de mejorar su forma de escribir las historias.
Una buena guía para redactar correctamente nuestras Historias de Usuario es seguir el acrónimo INVEST. Bill Wake, autor de libros como “Extreme Programming Explored” y “Refactoring Workbook”, sugirió este acrónimo en 2003 y viene a ser lo siguiente.
Toda historia debería ser INVEST:
Independent
Las historias deberían ser lo más independientes posible. Cuando dos historias son interdependientes:
- Siempre y cuando las historias sean pequeñas, plantéate unificarlas en una sola.
- Si no son pequeñas:
- Trata de fusionarlas y volver a fraccionarlas manteniendo el valor para el cliente y la dependencia. Muchas veces al fraccionar historias grandes no nos damos cuenta de que estamos generando dependencias.
- Si no es posible, eliminar esta dependencia simplemente asúmela y tenla en cuenta a la hora de planificar.
Negotiable
Las historias no son las extensas definiciones de requisitos que acostumbramos a ver. Deben ser lo suficientemente detalladas para que inviten a ser discutidas con el usuario en vista de recabar más información acerca de lo que se desea. Recuerda que las Historias de Usuario (Cards) invitan a la conversación con el usuario (Conversation) y se validan con los test (Confirmation). Ron Jeffries apuntaba a estas tres Cs como componentes de una historia en un artículo del 30 de agosto de 2001 de la revista XP Magazine: “Essential XP: Card, Conversation, and Confirmation”. Según va pasando el tiempo, y se va hablando con el usuario, la historia va adquiriendo más detalle. En un futuro, la historia puede ser dividida en varias más, e incluso podría llegar a ser desestimada si descubrimos que no aporta suficiente valor de negocio.
Valuable
Las historias tienen que aportar Valor al usuario. Historias con una redacción similar a “debe almacenarse en una base de datos MySQL” no aportan valor al usuario. El usuario suele ser agnóstico a la tecnología en la cual se apoya la funcionalidad. Pero si no fuese así y te encuentras con una historia técnica que aporte valor real al usuario, simplemente añádela. El valor de negocio es una herramienta muy importante para que el Product Owner priorice
las historias del Product Backlog. (ver artículo Product Backlog)
Estimable
Tienen que poderse estimar. La mayoría de las historias se suelen poder estimar mejor o peor. Pero generalmente hay tres escenarios en los cuales no se puede estimar una historia:
- Cuando el equipo no tiene información necesaria sobre ella. Simplemente bastaría con entablar más conversaciones con el usuario hasta tener el detalle necesario
- El equipo no tiene el conocimiento técnico suficiente para entender el cómo llevarlas a cabo. Quizás sea un buen momento para lanzar lo que en eXtreme Programming (XP) se denomina un spike. Un spike no es más que dedicar un tiempo fijo a investigar y realizar los experimentos que nos den la viabilidad o el conocimiento técnico que necesitamos para poder hacernos una idea de la complejidad de la Historia de Usuario.
- La historia es demasiado grande. Si la historia es demasiado grande, es muy difícil estimarla con fiabilidad (e incluso en algunos casos simplemente no podremos), y es difícil o a veces imposible que se amolde bien al Sprint. La solución a esto es simple, basta con fragmentar la historia en varias más pequeñas y más sencillas de trabajar. Y esto me lleva al siguiente punto …
Short
Las historias deberían ser lo suficientemente pequeñas para que:
- Sean fáciles de estimar
- Sea sencillo trabajar con ellas
- Se puedan ejecutar de forma independiente
- Se puedan acometer en un Sprint.
Testable
Las historias deben ser probables. La mejor prueba de que una Historia de Usuario está finalizada es que pase todos los test definidos para ella. Muchas veces confundimos un requisito no funcional del tipo “La página de alta ha de cargar rápidamente” con una Historia de Usuario. Los requisitos no funcionales (non functional requeriment NFR) pueden definirse en historia como tests, pero eso sí, de una forma … digamos más empírica. Un test adecuado a la NFR de arriba podría ser “La página de alta debería cargar el 92% de las veces en menos de 1 segundo”. No siempre es posible hacer esto último, pero en la medida de lo posible hay que escribir estos test de forma que sean poco ambiguos y fácilmente automatizables.
